Forwarding to the lists what I've just sent Jonathan... ---------- Forwarded message ---------- From: Vasile Gaburici <vgaburici@xxxxxxxxx> Date: Sun, Jul 27, 2008 at 7:23 PM To: Jonathan Underwood <jonathan.underwood@xxxxxxxxx> On Sun, Jul 27, 2008 at 5:59 PM, Jonathan Underwood <jonathan.underwood@xxxxxxxxx> wrote: > 2008/7/27 Vasile Gaburici <vgaburici@xxxxxxxxx>: >> 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 _______________________________________________ Fedora-fonts-list mailing list Fedora-fonts-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-fonts-list
