chris@mimsy.UUCP (Chris Torek) (07/10/88)
In article <330@marob.MASA.COM> samperi@marob.MASA.COM (Dominick Samperi) writes: >I noticed one curious thing about the font ilcmss8: ... all of the >characters in the font are blank! All the SliTeX i* fonts are blank. They are placeholders: {\red foo \blue bar} actually translates to (red slide) {\visible foo \invisible bar} % not in so many \words... but (blue slide) {\invisible foo \visible bar} % this is the idea (green slide) {\invisible foo \invisible bar} % if you had green, etc. The funny thing is that for most drivers, you have to generate great big (well...) PXL or GF or PK files just to say, `the letter a has no pixels, and b has no pixels, and c has no pixels, and ....' If every letter has no pixels, why not say so? Why not indeed? One reason is that you still have to describe the `bounding box' for the character. The point of the invisible `f' in the invisible `foo' is to take up *exactly* as much space as the visible `f' in the visible `foo', so that when the red and blue slides are combined, the words come out in the right places. That bounding box information appears in each of the various font file formats. But wait! That same information *also* appears in the TeX Font Metrics (TFM) files that LaTeX itself reads. Those files already must exist. Why not use them? And that is what my drivers do: # TYPE SPEC SLOP PATH font invis * 1 /usr/local/lib/tex/slitexfonts/%f.tfm The `slitexfonts' directory holds links to the i*.tfm files that appear in /usr/local/lib/tex/fonts. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
schoett@lan.informatik.tu-muenchen.dbp.de (Oliver Schoett) (07/13/88)
In article <12395@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > [Invisible fonts do not need a PK or GF or PXL file, because all a > device driver needs to know about them is the size of the bounding > box for each character, and that information is also present in the > fonts' TFM file.] This is not quite right. METAFONT occasionally creates character bitmaps whose dimensions do not match the (rounded) ideal measurements given in the TFM file. For example, in a nice lower-case 'm' the three stems should have an equal number of pixels, and so should the gaps between them. To accommodate this, the size of the resulting bitmap may have to be changed slightly from the (rounded) ideal value. This is described on p. 102 f. of the METAFONTbook. An application is the CMR roman lower-case 'm' on page 332 f. of "Computer Modern Typefaces". Information about the bitmap size for a certain resolution is contained in PK, GF, or PXL files. Device drivers should base their character positioning on the bitmap size as well as the TFM size of each character (the max_drift algorithm), and thus the bitmap size is required even for invisible fonts. I wish more device drivers would actually use the max_drift algorithm! Oliver Schoett schoett@lan.informatik.tu-muenchen.dbp.de schoett%lan.informatik.tu-muenchen.dbp.de@ {relay.cs.net, unido.uucp, ddoinf6.bitnet}
chris@mimsy.UUCP (Chris Torek) (07/22/88)
>In article <12395@mimsy.UUCP> I claimed that >>[Invisible fonts do not need a PK or GF or PXL file ....] In article <177@infovax.lan.informatik.tu-muenchen.dbp.de> schoett@lan.informatik.tu-muenchen.dbp.de (Oliver Schoett) writes: >This is not quite right. > >METAFONT occasionally creates character bitmaps whose dimensions do >not match the (rounded) ideal measurements given in the TFM file. ... >Information about the bitmap size for a certain resolution is >contained in PK, GF, or PXL files. Device drivers should base their >character positioning on the bitmap size as well as the TFM size of >each character (the max_drift algorithm), and thus the bitmap size is >required even for invisible fonts. This is indeed true. In many (not all!) cases, however, the drift slack will not affect those printing color slides. Since my invisible TFM `fonts' are easily configured out, and since I wanted various options for handling missing fonts (a variant of the `invisible' font is the `box' font, which prints a square box where TeX thinks the character goes) it cost essentially nothing to allow it as an option. >I wish more device drivers would actually use the max_drift algorithm! Mine do---indeed, I first noted the need for the drift algorithm with some text printed on a Versatec electrostatic printer (200 dpi). One of these days I shall have to write documentation for my code.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris