New subject: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]

27 Jul 2008


      Forwarding to the lists what I've just sent Jonathan...
---------- Forwarded message ----------
From: Vasile Gaburici vgaburici@gmail.com
Date: Sun, Jul 27, 2008 at 7:23 PM
To: Jonathan Underwood jonathan.underwood@gmail.com
On Sun, Jul 27, 2008 at 5:59 PM, Jonathan Underwood
jonathan.underwood@gmail.com wrote:
...
2008/7/27 Vasile Gaburici vgaburici@gmail.com:
...
So, Fedora would still have to ship TeX font files separately (for
some fonts) until the tool set and upstream OTF packaging matures. But
for mundane OTF fonts, which don't have optical sizes, I don't see
serious show stoppers for the proposal to (i) generate their .tfm TeX
metrics automatically, and (ii) convert them to type 1 on the user's
machine.
Why do (ii) on the users machine instead of at package build time?
Nicolas had some concerns on the size of font packages we ship,
especially when duplication is involved. I agree that doing the work
on the user's machine is somewhat contrary to the idea of RPM... BTW,
generating the tfm takes far more time and space. An extreme example
is MinionPro (full commercial set, from Adobe):
- OTFs:  10Mb
- PFBs:  20Mb
- TFMs: 180Mb
A single type 1 pfb file can contain more than 256 glyphs, but these
are addressable only by AGL (Adobe Glyph List) name. Traditinoal TeX
encodings (T1, LY1) are limited to 256 glyphs per font, so in order to
access all glyphs (e.g. small caps, lining figures) multiple tfm files
are generated for the same pfb. This wouldn't be much of a problem if
the tfm files didn't ALSO have to contain the kerning info! Take the
class-based kerning info from the OTF and make it pairwise, then put
overlapping subsets in multiple encodings and the disk usage
explodes... Sadly TeX cannot use Adobe's afm file format which could
at least store all the kerning pairs without duplication.
Btw, Linux Libertine or DejaVu have more glyphs than MinionPro...
...
These to jobs could be handled by a simple invocation of
...
autoinst (with some parameters, like telling it if the font is serif
or not). So, for most fonts the foo-font-tex package could be just
some emtpy dirs and a %post invocation of autoinst. This method needs
some testing with various fonts before we commit to it.
Again - why not use autoinst during package build time?
If Nicholas doesn't object, I surely don't. It would be a lot easier
to control what happens.
...
...
TrueType fonts can be used used without conversion by pdftex, but TeX
metrics still have to be generated. Other TeX drivers, like dvips and
dvipdfm, can use TrueType fonts only if they are converted to bitmaps;
I don't think this is worth the hassle since the output would suck on
screen.
I agree they suck.. but, not doing so would be a problem for legacy
users, I fear...
I doubt any legacy user uses »TrueType« fonts while generating
PostScript from TeX. Most legacy users that still rely on PostScript
output stick with Type 1 fonts, usually those that come with TeX
(Computer Modern, standard 35 PostScript fonts), because these can be
embedded as outlines in PostScript. Using TrueType fonts in TeX for
PostSript output is no different than using METAFONT fonts: PK bitmaps
have to be generated at the output resolution. Now, TeX doesn't ship
any bitmap PK fonts when METAFONT sources are available. TeX generates
(and caches) them as needed. Remember the old days when you had to
wait for "kpathsea: Running mktexpk --mfmode ..." I'm not aware of any
program that can do the magic for TrueType fonts, but I haven't used
TrueType fonts for PostScript output either. My point is that PK
bitmap generation is not something we want to do at packaging time!
-- Vasile

Fwd: TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]