CM-Super: Automatic Creation of Efficient Type 1 Fonts from Metafont
Total Page:16
File Type:pdf, Size:1020Kb
CM-Super: Automatic creation of efficient Type 1 fonts from METAFONT fonts Vladimir Volovich Voronezh State University Moskovsky prosp. 109/1, kv. 75, Voronezh 304077 Russia [email protected] Abstract In this article I describe making the CM-Super fonts: Type 1 fonts converted from METAFONT sources of various Computer Modern font families. The fonts contain a large number of glyphs covering writing in dozens of languages (Latin-based, Cyrillic-based, etc.) and provide outline replacements for the original METAFONT fonts. The CM-Super fonts were produced by tracing the high resolution bitmaps generated by METAFONT with the help of TEXtrace, optimizing and hinting the fonts with FontLab, and applying cleanups and optimizations with Perl scripts. 1 The idea behind the CM-Super fonts There exist free Type 1 versions of the original CM The Computer Modern (CM) fonts are the default fonts, provided by Blue Sky Research, Elsevier Sci- ence, IBM Corporation, the Society for Industrial and most commonly used text fonts with TEX. Orig- inally, CM fonts contained only basic Latin letters, and Applied Mathematics (SIAM), Springer-Verlag, and thus covered only the English language. There Y&Y and the American Mathematical Society, but are however a number of Computer Modern look- until not long ago there were no free Type 1 versions alike METAFONT fonts developed which cover other of other “CM look-alike” fonts available, which lim- languages and scripts. Just to name a few: ited their usage in PDF and PostScript target docu- ment formats. The CM-Super fonts were developed • EC and TC fonts, developed by J¨orgKnappen, to cover this gap. A which are the default LTEX fonts for the T1 and Such a conversion from METAFONT to Type 1 TS1 font encodings and cover many Latin-based fall into one of two general categories. First, base the scripts (mainly European). conversion on analytic study of the METAFONT out- • EC and TC Concrete and Bright fonts, devel- put (which may include “patching” the METAFONT oped by Walter Schmidt, which are additional program, analyzing the output of METAPOST, or font families containing the same glyphs as EC similar approaches). Such an approach can give and TC fonts. (potentially) the most accurate results, but I did • LH Cyrillic fonts, developed by Olga Lapko, not choose to use it, since it is much harder to de- which support the family of T2 font encodings: velop. (There are some commercial translators of T2A, T2B, T2C, X2, and others. They support METAFONT to Type 1 which I did not evaluate, the same font families as the original EC fonts, mainly due to their “closedness”, which I wanted EC Concrete and EC Bright fonts. to avoid.) The second, straightforward, approach is • TIPA (International Phonetic Alphabet) fonts, based on tracing the high-resolution bitmaps gen- developed by Rei Fukui, which support the T3 erated by METAFONT, and thus obtaining outline font encoding. There exist Concrete (CIPA) and versions of the fonts. Bright (BIPA) families of the TIPA fonts too. I was considering several approaches to con- METAFONT • FC fonts, developed by J¨org Knappen, which verting the fonts to Type 1 format — support the T4 font encoding for African lan- it seems that the GNU fontutils package developed guages. by Karl Berry is capable of this, but it had some problems with glyph positioning. Since the appear- • VNR fonts, developed by Cuong Nguyen, Wern- ance of T Xtrace, it became very easy to do this. er Lemberg and H`anThˆe´ Th`anh, which support E T Xtrace is a free automatic converter of META- the T5 font encoding for Vietnamese. E FONT fonts to Type 1 format, developed by P´eter • CBgreek fonts, developed by Claudio Beccari, Szab´o. It is based on Autotrace by Martin Weber. which support the Greek font encoding (LGR). TUGboat, Volume 24 (2003), No. 1 — Proceedings of the 2003 Annual Meeting 75 Vladimir Volovich And, as far as I know, some code was taken from additional Cyrillic and Latin glyphs which are not the GNU fontutils package. already present in supported encodings). It would be possible to simply generate Type 1 The original CM fonts used file names such as variants of all needed METAFONT fonts (each con- cmr10, cmbx12, etc., while their EC analogues use taining no more than 256 glyphs), but this will have font names consisting of four letters, the first two disadvantages: the total number of files will be truly of which are always “ec” while the second two de- vast (several thousands), and also the total size of note font family and shape: ecrm1000, ecbx1200, these fonts will be much bigger than necessary, be- etc. Design sizes are specified differently in the two cause of glyph duplication: Latin letters (and some families: EC fonts use a 4-digit scheme, while CM other characters and glyphs) will be present in more fonts use two digits. I’ve chosen to use font names than one font, e.g., the fonts ecrm1000 (T1 encod- of SuperFonts which follow the scheme used in EC ing), larm1000 (T2A), lbrm1000 (T2B), lcrm1000 fonts (with “sf” instead of “ec”, “tc”, etc.), since (T2C), fcr10 (T4), and vnrm1000 (T5) are all of the the majority of METAFONT fonts included into the same family and shape (Computer Modern Roman) CM-Super package follow this naming scheme (EC, and design size (10pt), and will thus duplicate at TC, LH). least the basic Latin alphabet. Given the total num- Families and shapes currently supported (the ber of font files (several thousands), such duplication README file in the CM-Super distribution contains a will give significant overhead. more detailed list): Thus, it seems natural to try to combine all 1. 29 font shapes supported by EC/TC fonts. Each fonts which have the same font family, shape and font shape comes in 14 font design sizes ranging design size, and differ only by font encoding (set from 5pt to 35.83pt (or 11 design sizes for type- of supported glyphs) into one SuperFont (the name writer font shapes ranging from 8pt to 35.83pt), comes from Karl Berry’s Fontname package), which giving 23 · 14 + 6 · 11 = 388 font files; will contain all the unique glyphs from these fonts 2. 13 font shapes for SliT X (each comes in one just once. Then it is possible to create map files for E design size); dvips, pdftex or other programs which will re-encode the big Super-fonts into specific 256-character font 3. 14 fonts from Computer Modern Concrete fam- encodings, selecting the glyphs needed for a partic- ily (font file names correspond to the scheme ular font encoding. used in EC Concrete fonts, again with “sf” in- Such an approach is undertaken in the CM- stead of “ec”); Super font package: each Type 1 SuperFont includes 4. 19 fonts from Computer Modern Bright family all the glyphs from several METAFONT fonts which (font file names correspond to the scheme used have the same font family, font shape and design in European Computer Modern Bright fonts). size. Currently, only text font encodings are sup- The total number of Type 1 font files included in ported. The name “super” does not imply that this the CM-Super package is 434. font collection contains Type 1 variants of all ex- Each Type 1 font contains glyphs from sev- isting CM look-alike fonts (e.g., there are no glyphs eral METAFONT fonts with the same font shape from math fonts in CM-Super), but that each font and design size. For example, sfrm1000.pfb com- in this collection is a SuperFont supporting many bines unique glyphs from the following METAFONT glyphs, languages, and scripts. These SuperFonts fonts: ecrm1000.mf, tcrm1000.mf, larm1000.mf, can be used with other applications as well as TEX. lbrm1000.mf, lcrm1000.mf, rxrm1000.mf (for en- codings T1, TS1, T2A, T2B, T2C, X2, respectively). 2 Font encodings, families, shapes, and In a future version, this font will also include names glyphs from tipa10.mf, fcr10.mf, vnrm1000.mf, The New Font Selection Scheme (NFSS) in LATEX grmn1000 (for font encodings T3, T4, T5, LGR). serves as a very good classifying mechanism in the Caps and small caps fonts do not include glyphs chaos of various fonts: each font is classified by its from TC fonts (TS1 font encoding), since there are encoding, family, shape and design size. The font no small caps TC fonts (but it may make sense to encoding defines the set (and order) of glyphs which include glyphs from the TS1 encoded fonts into these are contained in a font. Currently, the CM-Super fonts, for completeness, by duplicating glyphs from font collection supports glyphs from the following the corresponding non-smallcaps font shapes). LATEX font encodings: T1, TS1, T2A, T2B, T2C, X2. Our approach provides big savings: if we were In the near future I’ll try to add support for these making separate Type 1 fonts for each of the above encodings as well: T3, T4, T5, LGR, and others (e.g., mentioned METAFONT fonts, we would have 256 · 76 TUGboat, Volume 24 (2003), No. 1 — Proceedings of the 2003 Annual Meeting CM-Super: Automatic creation of efficient Type 1 fonts from METAFONT fonts 5 + 128 = 1408 glyphs from the five METAFONT At this point, we have “raw” Type 1 fonts which sources mentioned; but sfrm1000.pfb contains only should be optimized (which is done later). 585 unique glyphs, which includes some glyphs which Now we gather information contained in the were added for the sake of completeness. TFM files (which are generated by METAFONT), and The CM-Super fonts come with AFM and INF apply it to PFB files, and also create AFM font met- files and are thus usable with non-TEX-related ap- ric files.