[tex-live] [Fwd: [Fwd: ec.enc, cork.enc and tcaron]]

Zdenek Wagner zdenek.wagner at gmail.com
Tue Apr 15 23:26:16 CEST 2008

2008/4/15, Taco Hoekwater <taco at elvenkind.com>:
>  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.
> >
> http://www.fileformat.info/info/unicode/char/0165/index.htm
> > 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.
>  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.
I do not agree. This bug is ost evident if afm2tfm or a similar
program is asked to generate small caps font by scaling the uppercase
characters. When creating small caps /ccaron the program will look for
/Ccaron and scale it. If the program comes to /tquoteright, it would
like to scale /Tquoteright but such a character does not exist. The
character has meaning of /tcaron, its Unicode name is LATIN SMALL
LETTER T WITH CARON. Another problem arises 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. If the name is changed to /tquoteright, the
text is damaged in these operations.

>  Hope this helps,
>  Taco

Zdeněk Wagner

More information about the tex-live mailing list