[Fontinst] Mapping all diacritics to actual glyphs rather than composites

Lars Hellström Lars.Hellstrom at residenset.net
Fri Jan 15 15:13:17 CET 2010


Christopher Adams skrev:
> I'm presently using fontinst to create my own version of Palatino by
> combining URWPalladioL with the SC and OsF files from Adobe (thankfully they
> still sell these in Type1 format).
> 
> I noticed that for a large number of accented characters that are defined by
> T1, in the output from pdflatex they are being drawn as composite glyphs,
> rather than independent glyphs as they exist in the Palladio fonts.

Just to be clear here: By "composite" you mean that there are really 
two glyphs being combined to make up one letter?

I first felt a bit confused when reading this, but that's probably 
because I've been thinking about Unicode lately, where (the semantic 
counterpart of) this kind of thing would be called "decomposed".

> For glyphs such as *gbreve* this makes no difference in the final output.
> For others such as *eogonek,* the ogonek is misplaced*

Yes, getting the position of the ogonek right is tricky.

> (and anyway you can't
> make a good *eogonek* by compositing; it really needs to be an independent
> glyph.). Likewise the *dcaron* and *tcaron* are wrong, because again you
> can't achieve good glyphs by compositing the base character with an
> apostrophe.

Still, they're not quite as bad as some other glyphs being faked, I 
suspect.

> Why are these glyphs being created through composites rather than being
> taken from the font? Is this a limitation of Adobe Standard Encoding? I've
> tried studying the different encodings but I'm not sure how to apply them to
> solve this problem.

Not of the StandardEncoding as such, since fontinst doesn't create 
composite glyphs in the Type 1 (seac charstring operation) sense, but 
quite likely a limitation of the TeXBase1Encoding (8r) in that it 
doesn't encode all the glyphs you have in the font. This, in turn, is a 
consequence of PostScript (1980's design that it is) only allowing 
8-bit encodings; no single encoding can cover more than 256 glyphs.

You need to use a different base font encoding, either instead of or in 
addition to, 8r. The quickest way of getting one that covers the glyphs 
you're asking about would probably be to use the T1 encoding itself; a 
variant on that trick is described in
   http://tug.org/pipermail/fontinst/2009/001615.html
and forth, though in that case t1cj.etx was used to gain access to 
smallcaps and oldstyle figure glyphs.

> * As an aside, the ogoneks in PalladioL are really badly drawn. One aim of
> my project is to redraw these glyphs in a separate font and bring them into
> to my Palatino via fontinst.

Good choice. Combining the offerings of several base fonts is where 
fontinst really shines.

Lars Hellström




More information about the fontinst mailing list