I wonder, \definecharacter Aring {\ilencodedrA} \definecharacter Lstroke {\ilencodedL} \definecharacter lstroke {\ilencodedl} where do these come from? is that because csr does not provide those glyphs? (which makes il2 like aer (almoet ec) something almost il2 -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen wrote:
I wonder,
\definecharacter Aring {\ilencodedrA}
\definecharacter Lstroke {\ilencodedL} \definecharacter lstroke {\ilencodedl}
where do these come from? is that because csr does not provide those glyphs?
il2 encoding is not ISO-8859-2 but encoding of CS fonts (csr...). It was derived from ISOO-8859-2 but: - first 128 glyphs are the same as cmr... - upper part is added according to ISO-8859-2 (http://nl.ijs.si/gnusl/cee/charset.html) but only chars needed for Czech/Slovak lang. Neither Aring is present in CSfont, nor Lstroke, nor lstroke.
(which makes il2 like aer (almoet ec) something almost il2 -)
I have mentioned that when I was interested in CMAP. --- I entered these three chars definitions when I was preparing support for Storm's fonts last weekend. It is a large collection (about 50 families) of commercial fonts with large glyph set each (about 370). Since there are prepared large collectin of tfm (t1 or il2 + one extended) from Petr Olsak I decided to use them. I prepared enco-st2.tex (storm il2) and enco-st3.tex (storm extended) for now (I intended also enco-st1 for t1). The question is how to elegantly switch from standard (st2) tfm to extended (st3) tfm when the glyph is not present in st2 - with preserving \rm, \bf, \it, \bi. Example: {\bf Bold text with special char \textplus} where \texplus is bold variant from st3 encoded tfm. It is understandable? Vit
Vit Zyka said this at Wed, 9 Feb 2005 22:34:13 +0100:
The question is how to elegantly switch from standard (st2) tfm to extended (st3) tfm when the glyph is not present in st2 - with preserving \rm, \bf, \it, \bi.
Example: {\bf Bold text with special char \textplus} where \texplus is bold variant from st3 encoded tfm. It is understandable?
Interesting. There are a couple possibilities, I think. My current favourite, \variant[something], is essentially a convention that's built on top of the font synonym mechanism. There's an example given at: http://contextgarden.net/Font_Variants ...but I haven't done a proper write-up yet. basically, you declare a variant set for a (Serif/Sans/Mono) family: \definefontvariant [Serif] [exp] [-Expert] % [fam] [call abbrev] [synonym suffix] And then you create font synonyms for each of the possible seven SerifBlah-Expert fonts that would be called, e.g.: \definefontsynonym [SerifRegular] [AndulkaText] \definefontsynonym [SerifRegular-Expert] [AndulkaTextExpert] \definefontsynonym [SerifBold] [AndulkaTextBold] \definefontsynonym [SerifBold-Expert] [AndulkaTextBoldExpert] Where the AndulkaText font resolves to your st2 encoding, and AndulkaTextExpert is in your st3 encoding. (I haven't tried this trick with different encodings, but it *should* work!) You can then call the proper variant with {\bf Hi there \Var[exp]+}, or create a level of indirection with your \textplus macro so that it calls the [exp] variant and the glyph together. The Storm fonts are beautiful. Sigh. Have fun with them... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay, Computing Dept. atl@comp.lancs.ac.uk Lancaster University, InfoLab21 +44(0)1524/510.514 Lancaster, LA1 4WA, UK Fax:+44(0)1524/510.492 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Adam Lindsay wrote:
Vit Zyka said this at Wed, 9 Feb 2005 22:34:13 +0100:
The question is how to elegantly switch from standard (st2) tfm to extended (st3) tfm when the glyph is not present in st2 - with preserving \rm, \bf, \it, \bi.
Example: {\bf Bold text with special char \textplus} where \texplus is bold variant from st3 encoded tfm. It is understandable?
Interesting. There are a couple possibilities, I think. My current favourite, \variant[something], is essentially a convention that's built on top of the font synonym mechanism. There's an example given at: http://contextgarden.net/Font_Variants ...but I haven't done a proper write-up yet.
basically, you declare a variant set for a (Serif/Sans/Mono) family: \definefontvariant [Serif] [exp] [-Expert] % [fam] [call abbrev] [synonym suffix]
And then you create font synonyms for each of the possible seven SerifBlah-Expert fonts that would be called, e.g.:
\definefontsynonym [SerifRegular] [AndulkaText] \definefontsynonym [SerifRegular-Expert] [AndulkaTextExpert] \definefontsynonym [SerifBold] [AndulkaTextBold] \definefontsynonym [SerifBold-Expert] [AndulkaTextBoldExpert]
Where the AndulkaText font resolves to your st2 encoding, and AndulkaTextExpert is in your st3 encoding. (I haven't tried this trick with different encodings, but it *should* work!)
You can then call the proper variant with {\bf Hi there \Var[exp]+}, or create a level of indirection with your \textplus macro so that it calls the [exp] variant and the glyph together.
The Storm fonts are beautiful. Sigh. Have fun with them...
Thank you, Adam, for tips and explanation. Now I am a bit short of time, but after that I will have a look at it. And want introduce the Storm font support. But ... seeing Andulka, some support has already exists there, has not it? I would not like to discover wheel ;-) Vit
Vit Zyka said this at Thu, 10 Feb 2005 00:33:59 +0100:
But ... seeing Andulka, some support has already exists there, has not it? I would not like to discover wheel ;-)
no, it's just a trick of the light. I picked that font name just as a dummy example to get your attention. :) I can't afford to go shopping at Storm, sadly. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay, Computing Dept. atl@comp.lancs.ac.uk Lancaster University, InfoLab21 +44(0)1524/510.514 Lancaster, LA1 4WA, UK Fax:+44(0)1524/510.492 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Adam Lindsay wrote:
Vit Zyka said this at Thu, 10 Feb 2005 00:33:59 +0100:
But ... seeing Andulka, some support has already exists there, has not it? I would not like to discover wheel ;-)
no, it's just a trick of the light. I picked that font name just as a dummy example to get your attention. :) I can't afford to go shopping at Storm, sadly.
an impressive collection of fonts indeed, very nice packaging as well; in a sense the 'whole collection cd' is not even that expensive compared to other collections but i can't afford it either -) concerning typescripts: i stongly advise to look into the possibility to use qx (or ec or texnansi) for the font encoding instead of il2, one can always use il2 as regime to map the il2 input onto that. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen wrote:
Adam Lindsay wrote:
Vit Zyka said this at Thu, 10 Feb 2005 00:33:59 +0100:
But ... seeing Andulka, some support has already exists there, has not it? I would not like to discover wheel ;-)
no, it's just a trick of the light. I picked that font name just as a dummy example to get your attention. :) I can't afford to go shopping at Storm, sadly.
an impressive collection of fonts indeed, very nice packaging as well; in a sense the 'whole collection cd' is not even that expensive compared to other collections but i can't afford it either -)
I also do not own the whole set :-(, only Czech Type Library Collection (about 8 families). And am I very satisfy.
concerning typescripts: i stongly advise to look into the possibility to use qx (or ec or texnansi) for the font encoding instead of il2, one can
Metric are prepared for t1 and il2. Both I want to support (AFAIK texansi is t1, is'n it?). I would like to avoid new *.tfm preparation. Perhaps fontutil can help but I do not know if substantially in case of such huge collection of glyphs. vit
Adam Lindsay wrote:
Vit Zyka said this at Wed, 9 Feb 2005 22:34:13 +0100:
The question is how to elegantly switch from standard (st2) tfm to extended (st3) tfm when the glyph is not present in st2 - with preserving \rm, \bf, \it, \bi.
basically, you declare a variant set for a (Serif/Sans/Mono) family: \definefontvariant [Serif] [exp] [-Expert] % [fam] [call abbrev] [synonym suffix]
Hallo, thanks to Adam, it was easy to implement font variants. A little bit more work was with all Storm glyph deffinition in two (+one) encodings. Before I will do the support for the rest of my Storm font families I want to ask audience (and especially Hans, Adam) to have a look into the files (http://typokvitek.com/tmp/context-storm.zip). Example in http://typokvitek.com/tmp/test-sdynamo.pdf (generaly interesting for all \show... font related command usage). Recommendation for the package improvements are welcomed. There are: enco-st1.tex - ec encoding with storm glyph extension enco-st2.tex - xl2 encoding with storm glyph extension enco-st3.tex - variants (additional glyph) for enco-st1 and enco-st2 type-sdynamo.tex - typescripts for Storm Dynamo font family math-sto.tex - simple mathematics present in Storm fonts (in progress) test-sdynamo.tex - test file test-storm.tex - support for tests Questions: ? During encoding deffinition I found some chracter name mess. I solved it by synonyms: E.g. \definecharacter textdag {\dagger} \definecharacter paragraphmark {\paragraph} \definecharacter textellipsis {\ellipsis} \definecharacter textminus {\minus} \definecharacter ostroke {\oslash} \definecharacter textdollar {\dollar} Is there some context convention for character names? ? I have a problem to define mathematics chars. I did: \starttypescript [math] [dynamoRE] [st1] \definefontsynonym [DynamoRE-Math-Letters] [sdgr8te] [encoding=st1] \definefontsynonym [DynamoRE-Math-Letters-Italic] [sdgri8te] [encoding=st1] \definefontsynonym [DynamoRE-Math-Symbols] [sdgr8te] % \definefontsynonym [DynamoRE-Math-Extension] [] \stoptypescript \starttypescript [math] [dynamoRE] [name] \definefontsynonym [MathRoman] [DynamoRE-Math-Letters] \definefontsynonym [MathItalic] [DynamoRE-Math-Letters-Italic] \definefontsynonym [MathSymbol] [DynamoRE-Math-Symbols] \definefontsynonym [MathExtension] [ComputerModernMath-Extension] \stoptypescript \starttypescript [DynamoRE] [st1,st2] \definetypeface [DynamoRE] [ss] [sans] [dynamoRE] [default] [encoding=\typescripttwo] \definetypeface [DynamoRE] [mm] [math] [dynamoRE] [default] [encoding=\typescripttwo] \stoptypescript \startmathcollection[storm] \definemathcharacter [+] [bin] [sy] ["2B] \definemathcharacter [=] [rel] [sy] ["3B] \stopmathcollection \enablemathcollection[storm] $1+1=2$ But I get error: !Math formula deleted: Insufficient symbol fonts. Where is the problem? ? - \starttypescript [*] [fallback] is generaly useful. Is a good idea to move it from large type-buy.tex somewhere else? ? Storm fonts have different accent shapes for lover/upper case letters. Is there some mechanism to distinguish this making the composits? Thank you Vit
Vit Zyka wrote:
Adam Lindsay wrote:
Vit Zyka said this at Wed, 9 Feb 2005 22:34:13 +0100:
The question is how to elegantly switch from standard (st2) tfm to extended (st3) tfm when the glyph is not present in st2 - with preserving \rm, \bf, \it, \bi.
basically, you declare a variant set for a (Serif/Sans/Mono) family: \definefontvariant [Serif] [exp] [-Expert] % [fam] [call abbrev] [synonym suffix]
Hallo,
thanks to Adam, it was easy to implement font variants. A little bit more work was with all Storm glyph deffinition in two (+one) encodings. Before I will do the support for the rest of my Storm font families I want to ask audience (and especially Hans, Adam) to have a look into the files (http://typokvitek.com/tmp/context-storm.zip). Example in http://typokvitek.com/tmp/test-sdynamo.pdf (generaly interesting for all \show... font related command usage). Recommendation for the package improvements are welcomed.
There are: enco-st1.tex - ec encoding with storm glyph extension enco-st2.tex - xl2 encoding with storm glyph extension enco-st3.tex - variants (additional glyph) for enco-st1 and enco-st2 type-sdynamo.tex - typescripts for Storm Dynamo font family math-sto.tex - simple mathematics present in Storm fonts (in progress) test-sdynamo.tex - test file test-storm.tex - support for tests
Questions:
? During encoding deffinition I found some chracter name mess. I solved it by synonyms: E.g. \definecharacter textdag {\dagger} \definecharacter paragraphmark {\paragraph} \definecharacter textellipsis {\ellipsis} \definecharacter textminus {\minus} \definecharacter ostroke {\oslash} \definecharacter textdollar {\dollar} Is there some context convention for character names?
? I have a problem to define mathematics chars. I did: \starttypescript [math] [dynamoRE] [st1] \definefontsynonym [DynamoRE-Math-Letters] [sdgr8te] [encoding=st1] \definefontsynonym [DynamoRE-Math-Letters-Italic] [sdgri8te] [encoding=st1] \definefontsynonym [DynamoRE-Math-Symbols] [sdgr8te] % \definefontsynonym [DynamoRE-Math-Extension] [] \stoptypescript
\starttypescript [math] [dynamoRE] [name] \definefontsynonym [MathRoman] [DynamoRE-Math-Letters] \definefontsynonym [MathItalic] [DynamoRE-Math-Letters-Italic] \definefontsynonym [MathSymbol] [DynamoRE-Math-Symbols] \definefontsynonym [MathExtension] [ComputerModernMath-Extension] \stoptypescript
\starttypescript [DynamoRE] [st1,st2] \definetypeface [DynamoRE] [ss] [sans] [dynamoRE] [default] [encoding=\typescripttwo] \definetypeface [DynamoRE] [mm] [math] [dynamoRE] [default] [encoding=\typescripttwo] \stoptypescript
\startmathcollection[storm] \definemathcharacter [+] [bin] [sy] ["2B] \definemathcharacter [=] [rel] [sy] ["3B] \stopmathcollection
\enablemathcollection[storm]
$1+1=2$
But I get error: !Math formula deleted: Insufficient symbol fonts. Where is the problem?
? - \starttypescript [*] [fallback] is generaly useful. Is a good idea to move it from large type-buy.tex somewhere else?
? Storm fonts have different accent shapes for lover/upper case letters. Is there some mechanism to distinguish this making the composits?
Thank you Vit _______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Vit Zyka wrote:
But I get error: !Math formula deleted: Insufficient symbol fonts. Where is the problem?
it means that your font is not a proper math font, taco may know how to deal with this
? - \starttypescript [*] [fallback] is generaly useful. Is a good idea
replaced by a (faster) setup)
to move it from large type-buy.tex somewhere else?
see type-def.tex: \startsetups [font:fallback:serif] \definefontsynonym [Serif] [DefaultFont] \definefontsynonym [SerifBold] [Serif] \definfontsynonym [SerifItalic] [Serif] \definefontsynonym [SerifSlanted] [SerifItalic] \definefontsynonym [SerifBoldItalic] [Serif] \definefontsynonym [SerifBoldSlanted] [SerifBoldItalic] \definefontsynonym [SerifCaps] [Serif] \stopsetups \starttypescript .... \setups[font:fallback:serif] your defs \stoptypescript (see type-msw for an example) this construct is faster since it does not need a nested typescript scan
? Storm fonts have different accent shapes for lover/upper case letters. Is there some mechanism to distinguish this making the composits?
interesting, \' etc are not sufficient fot that \definecommand UCgrave {\buildtextaccent\UCtextgrave} \definecommand UCacute {\buildtextaccent\UCtextacute} \definecommand UCring {\buildtextaccent\UCtextring} \definecommand UCcaron {\buildtextaccent\UCtextcaron} \definecommand UCbreve {\buildtextaccent\UCtextbreve} \definecommand UCmacron {\buildtextaccent\UCtextmacron} \definecommand UCcircumflex {\buildtextaccent\UCtextcircumflex} \definecommand UCdotaccent {\buildtextaccent\UCtextdotaccent} \definecommand UChungarumlaut {\buildtextaccent\UCtexthungarumlaut} \definecommand UCtilde {\buildtextaccent\UCtexttilde} \definecommand UCdiaeresis {\buildtextaccent\UCtextdiaeresis} \startencoding [default] \definecharacter UCtextgrave {\textgrave} ..... \stopencoding \startencoding [yours] \definecharacter Ediaeresis {\buildtextaccent\UCtextdiaeresis E} ... \stopencoding etc etc; needs some thinking and testing and quite some keying Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen wrote:
Vit Zyka wrote:
it means that your font is not a proper math font, taco may know how to deal with this
? - \starttypescript [*] [fallback] is generaly useful. Is a good idea
replaced by a (faster) setup)
to move it from large type-buy.tex somewhere else?
see type-def.tex:
\startsetups [font:fallback:serif]
Thank you Hans for a hint. I did not know about font setups.
? Storm fonts have different accent shapes for lover/upper case letters. Is there some mechanism to distinguish this making the composits?
interesting, \' etc are not sufficient fot that
\definecommand UCgrave {\buildtextaccent\UCtextgrave}
\startencoding [default] \definecharacter UCtextgrave {\textgrave} ..... \stopencoding
\startencoding [yours] \definecharacter Ediaeresis {\buildtextaccent\UCtextdiaeresis E} ... \stopencoding
I Understand, thank you, I will both incorporate it into Storm support. Vit
Vit Zyka said this at Tue, 15 Mar 2005 19:23:05 +0100:
enco-st1.tex - ec encoding with storm glyph extension enco-st2.tex - xl2 encoding with storm glyph extension enco-st3.tex - variants (additional glyph) for enco-st1 and enco-st2
Vit, I would refer you to this thread with Thomas Schmitz on "variant encodings": http://www.ntg.nl/pipermail/ntg-context/2005/009057.html I'd call your st1 an EC variant, st2 an XL2 variant, and st3 some sort of custom expert encoding. Ultimately names aren't *that* important, but they can help a lot when others try to pick up and understand your work.
? I have a problem to define mathematics chars. I did: \starttypescript [math] [dynamoRE] [st1] \definefontsynonym [DynamoRE-Math-Letters] [sdgr8te] [encoding=st1] \definefontsynonym [DynamoRE-Math-Letters-Italic] [sdgri8te] [encoding=st1] \definefontsynonym [DynamoRE-Math-Symbols] [sdgr8te] % \definefontsynonym [DynamoRE-Math-Extension] [] \stoptypescript
But I get error: !Math formula deleted: Insufficient symbol fonts. Where is the problem?
I don't know. In doing some math font adaptations, I haven't run into that error message. Basically, with all the mathematics work you're proposing, I don't have enough information to follow what you did and to help. Were there any .enc files you created for these math fonts? How did you install them? Math fonts generally require different metrics.
? - \starttypescript [*] [fallback] is generaly useful. Is a good idea to move it from large type-buy.tex somewhere else?
Have you looked at ThisWay #9 yet? http://pragma-ade.com/show-mag-10.htm I haven't had a chance to play with them yet, but the \setups[font: fallback:sans] look to be helpful.
? Storm fonts have different accent shapes for lover/upper case letters. Is there some mechanism to distinguish this making the composits?
I don't know. But I presume that you're play^H^H^H^Hexperimenting with these customised encodings because you want to use the full complement of designed characters, right? How many of these composite characters will you be needing? cheers, adam -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay, Computing Dept. atl@comp.lancs.ac.uk Lancaster University, InfoLab21 +44(0)1524/510.514 Lancaster, LA1 4WA, UK Fax:+44(0)1524/510.492 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Adam Lindsay wrote:
Vit Zyka said this at Tue, 15 Mar 2005 19:23:05 +0100:
enco-st1.tex - ec encoding with storm glyph extension enco-st2.tex - xl2 encoding with storm glyph extension enco-st3.tex - variants (additional glyph) for enco-st1 and enco-st2
Vit,
I would refer you to this thread with Thomas Schmitz on "variant encodings": http://www.ntg.nl/pipermail/ntg-context/2005/009057.html
I'd call your st1 an EC variant, st2 an XL2 variant, and st3 some sort of custom expert encoding. Ultimately names aren't *that* important, but they can help a lot when others try to pick up and understand your work.
Thank you Adam for your suggestion. Your naming convention has a logic. The reason why I do not use it is that I utilized work of Petr Olsak. I am using all *.tfm, *.map and *.enc files. I believe it is not a drawback for ConTeXt but it is advantage for me: do not prepare hundreds of metric files.
? I have a problem to define mathematics chars. I did: \starttypescript [math] [dynamoRE] [st1] \definefontsynonym [DynamoRE-Math-Letters] [sdgr8te] [encoding=st1] \definefontsynonym [DynamoRE-Math-Letters-Italic] [sdgri8te] [encoding=st1] \definefontsynonym [DynamoRE-Math-Symbols] [sdgr8te] % \definefontsynonym [DynamoRE-Math-Extension] [] \stoptypescript
But I get error: !Math formula deleted: Insufficient symbol fonts. Where is the problem?
Answer: math family 2 (Math-Symbols) needs extended (math) metric. So I switched back to cmsy10. The same for family 3 (Math-Extension).
I haven't had a chance to play with them yet, but the \setups[font: fallback:sans] look to be helpful.
Interesting, I used it.
? Storm fonts have different accent shapes for lover/upper case letters. Is there some mechanism to distinguish this making the composits?
It is incorporated like \UCtilde{I}. But hardly needed for Storm since nearly all imaginable accented letter are pressent as a single glyph. I only defined this way: Ygrave, Ytilde, Ibreve, Ycaron, Etilde. For details, see enco-st1.tex or enco-st2.tex vit
Vit Zyka said this at Sun, 10 Apr 2005 22:31:50 +0200:
I'd call your st1 an EC variant, st2 an XL2 variant, and st3 some sort of custom expert encoding. Ultimately names aren't *that* important, but they can help a lot when others try to pick up and understand your work.
Thank you Adam for your suggestion. Your naming convention has a logic. The reason why I do not use it is that I utilized work of Petr Olsak. I am using all *.tfm, *.map and *.enc files. I believe it is not a drawback for ConTeXt but it is advantage for me: do not prepare hundreds of metric files.
I actually had gone back and re-thought that suggestion (especially after examining Olsak's OFS in further detail). As the st1 does have *character* (and not just *glyph*) differences from EC, it really is a different encoding. Again, great stuff. Thanks! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay, Computing Dept. atl@comp.lancs.ac.uk Lancaster University, InfoLab21 +44(0)1524/510.514 Lancaster, LA1 4WA, UK Fax:+44(0)1524/510.492 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Vit Zyka wrote:
Hans Hagen wrote:
I wonder,
\definecharacter Aring {\ilencodedrA}
\definecharacter Lstroke {\ilencodedL} \definecharacter lstroke {\ilencodedl}
where do these come from? is that because csr does not provide those glyphs?
il2 encoding is not ISO-8859-2 but encoding of CS fonts (csr...). It was derived from ISOO-8859-2 but: - first 128 glyphs are the same as cmr... - upper part is added according to ISO-8859-2 (http://nl.ijs.si/gnusl/cee/charset.html) but only chars needed for Czech/Slovak lang.
Neither Aring is present in CSfont, nor Lstroke, nor lstroke.
(which makes il2 like aer (almoet ec) something almost il2 -)
I have mentioned that when I was interested in CMAP.
---
I entered these three chars definitions when I was preparing support for Storm's fonts last weekend. It is a large collection (about 50 families) of commercial fonts with large glyph set each (about 370). Since there are prepared large collectin of tfm (t1 or il2 + one extended) from Petr Olsak I decided to use them. I prepared enco-st2.tex (storm il2) and enco-st3.tex (storm extended) for now (I intended also enco-st1 for t1). The question is how to elegantly switch from standard (st2) tfm to extended (st3) tfm when the glyph is not present in st2 - with preserving \rm, \bf, \it, \bi.
Example: {\bf Bold text with special char \textplus} where \texplus is bold variant from st3 encoded tfm. It is understandable?
I wonder, why don't you use the more recent qx encoding; if il2 is only used for csr, then we can best extend il2 encoding since all the chars missing in csr are present in latin modern; Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen wrote:
Vit Zyka wrote:
Hans Hagen wrote:
I wonder,
\definecharacter Aring {\ilencodedrA}
\definecharacter Lstroke {\ilencodedL} \definecharacter lstroke {\ilencodedl}
where do these come from? is that because csr does not provide those glyphs?
il2 encoding is not ISO-8859-2 but encoding of CS fonts (csr...). It was derived from ISOO-8859-2 but: - first 128 glyphs are the same as cmr... - upper part is added according to ISO-8859-2 (http://nl.ijs.si/gnusl/cee/charset.html) but only chars needed for Czech/Slovak lang.
Neither Aring is present in CSfont, nor Lstroke, nor lstroke.
(which makes il2 like aer (almoet ec) something almost il2 -)
I wonder, why don't you use the more recent qx encoding;
if il2 is only used for csr, then we can best extend il2 encoding since all the chars missing in csr are present in latin modern;
Problem is that il2 and ISO-8859-2 differs in next chars presented in il2: dec ISO CS 184 cedilla \`a 254 tcedilla dblleftquote 255 dot above dblrightquote ... After some quotes (e.g. Adams'
"The Polish prefer it more upright. The Czechs prefer it more flat."
) I feel stronger and stronger that csr should coexist with lm for future. Perhaps like a option (not present in minimal distr?), but with full functionality if extra loaded. So I would like il2 will be preserved as it is and new coding according to lm (ISO-8859-2 ?) would be introduce (enco-l2 ?). Vit
Vit Zyka wrote:
) I feel stronger and stronger that csr should coexist with lm for future. Perhaps like a option (not present in minimal distr?), but with full functionality if extra loaded.
about how many to be czechified chars are we talking?
So I would like il2 will be preserved as it is and new coding according to lm (ISO-8859-2 ?) would be introduce (enco-l2 ?).
how about il2 as input encoding and another one for the fonts? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen wrote:
Vit Zyka wrote:
) I feel stronger and stronger that csr should coexist with lm for future. Perhaps like a option (not present in minimal distr?), but with full functionality if extra loaded.
about how many to be czechified chars are we talking?
About 33 Czech glyphs (+5 or 7 more Slovak).
So I would like il2 will be preserved as it is and new coding according to lm (ISO-8859-2 ?) would be introduce (enco-l2 ?).
how about il2 as input encoding and another one for the fonts?
Yes. True is that ISO-8859-2 is a correct input regime. So far il2 is more font-specific coding (*.enc). We can discuss their names. If we change il2 regime to ISO... AFAIK we have to prepare new - set of csr.enc, csr1.enc, csin.enc, and cstt.enc - map file - metric files cs*.tfm If we preserve \enableregime[il2] and prepare \enableregime[l2] or something like, all no additional work and backward compatibility problems occure? Am I right? vit
participants (3)
-
Adam Lindsay -
Hans Hagen -
Vit Zyka