[tex-live] [Fwd: [Fwd: ec.enc, cork.enc and tcaron]]
vit.zyka at gmail.com
Wed Apr 16 11:03:51 CEST 2008
Hellow Taco and others, please read bellow:
Taco Hoekwater wrote:
> Hi Vit,
> Jim Hefferon wrote:
>> Please forgive the forward; I don't understand anything about encodings
>> myself so I can only pass on the report whole. Vit Zyka wrote me the
>> message below.
>> -------- Forwarded Message --------
>> From: Vit Zyka <vit.zyka munging gmail.com>
>> To: ftpmaint munging alan.smcvt.edu
>> Subject: [Fwd: ec.enc, cork.enc and tcaron]
>> Date: Mon, 14 Apr 2008 13:12:34 +0200
>> Dear Jim,
>> I do not know who is responsible for a next bug; in the cork.enc file
>> I find address <tex-fonts at tug.org> but my mail returned back
>> undelivered. So I am sending this bug to you are the CTAN maintainer.
>> Please, might you correct it yourself or resent to a responsible person?
>> There is wrongly named the glyph 'tcaron' by 'tquoteright' in the files
>> ec.enc and cork.enc. It is really bug, see e.g.
>> Due to the fact the glyph is simply missing using some fonts in the
>> resulted documents.
> ... and may be present in others.
> Encoding files that are syntactically correct and succeed in creating
> a PostScript array of length 256 containing names are bugfree when they
> are used with a font that uses these names to indentify charstrings.
Yes, Taco, you are right the bug in [ec|cork].enc sould be solved in
conjunction with the fonts.
Let as look to the TeX Live 2007 temxmf-dist/fonts directory. Command
grep -S "tquoteright" *.*
.\afm\ibm\courier\cour.afm:C -1 ; WX 600 ; N tquoteright ; B 73 -14 646
... next 7 font variant
.\afm\ibm\times\nntb8a.afm:C -1 ; WX 521 ; N tquoteright ; B 0 -6 493 677 ;
... next 7 font variant
.\enc\dvips\base\cork.enc: /tquoteright /tcedilla /uhungarumlaut /uring
.\enc\dvips\base\ec.enc: /tquoteright /tcedilla /uhungarumlaut /uring
.\enc\dvips\base\tex256.enc:/tcaron % 180 % /tquoteright
1. tex256.enc has been corrected yet.
2. The only fonts that use buggy name are ibm/courier and ibm/times
Total number of afm files that use tquoteright is 16.
3. Total number of afm files that use tcaron is 12848(!).
4. cork.enc is not used in *.map at all
5. ec.enc is used for 611 fonts in *.map
6. none of ibm fonts in tfm/ibm/*
and their variants)
is present in *.map; so no change for these fonts is needed if
we correct the enc files.
7. Except of missing of \v t in the text, Zdenek Wagner summarized the
next problems with 'tquoteright':
> * if afm2tfm or a similar program is asked to generate
> small caps font by scaling the uppercase characters.
> When creating small caps /tcaron the program will
> look for /Tcaron and scale it.
> * The character has meaning of /tcaron, its Unicode name is
> LATIN SMALL LETTER T WITH CARON.
> * when searching PDF or when cutting&pasting the texts
> from PDF via a clipboard. If /toUnicode map
> is not inserted, the algorithm relies upon the postscript
> names and /tcaron is expected here.
A) rename (for hypothetic use with font like ibm)
en.enc -> ec-old.enc
cork.enc -> cork-old.enc
B) correct glyph name /tquoteright -> /tcaron in
These steps should not cause any back compatibility problems. Despite
this if some occurs we will solve it by using *-old.enc in map files or
discussing the glyph name with the font authors.
Alternatively, we can create new file ec-correct.enc and to change six
hundreds lines or so in *.map to point to this new file. I see these
a) more work, more affected files
b) confusion for users since there exist manuals that advise to use
ec.enc file (e.g. afm2tfm, pdftex).
Preserving on the present encoding vectors is a bug that causes problems
to users. Please, let us try to solve it.
> Whether or not these particluar names are used in any font is another
> matter, and that is why the latin modern fonts come with their own
> files (lm-ec.enc, I believe). Various fonts use various 'names' for
> their glyphs, and an .enc file *has to* abide to whatever convention
> the font designer has chosen.
> This cork.enc may show buggy behaviour when combined with the font
> it is tied to in your psfonts.map or pdftex.map (and if that came from
> texlive, then there is a bug in the map file) but the encoding file
> itself is still correct even in that case.
> Hope this helps,
Ing. Vít Zýka, Ph.D. TYPOkvítek, Czech Republic
computer vision application aplikace pocitacoveho videni
database publishing databazove publikovani
scientific book typesetting sazba odbornych publikaci
tel.: (+420) 777 198 189 www: http://typokvitek.com
More information about the tex-live