Hagen - Pragma ADE
Hagen - Pragma ADE Hagen - Pragma ADE
14 Font formats can be rules that turn 1/2 into one glyph, or transfer the numbers into superior and inferior alternatives, but leaves us with an unacceptable rendered 1/a, given that the frac features is enabled. It looks like features like this are to be applied to a manually selected range of characters. The fact that an OpenType font can contain many features and rules to apply them makes it possible to typeset scripts like Arabic. And this is where it gets vague. A generic OpenType sub-engine can do clever things using these rules, but if you read the specification for some scripts additional intelligence has to be provided by the typesetting engine. While users no longer have to care about encodings, map files and back-end issues, they do have to carry knowledge about the possibilities and limitations of features. Even worse, he or she needs to be aware that fonts can have bugs. Also, as font vendors have no tradition of providing updates this is something that we might need to take care of ourselves by tweaking the engine. One of the problems with the transition from Type1 to OpenType is that font designers can take an existing design and start from that basic repertoire of shapes. If such a design had oldstyle figures only, there is a good chance that this will be the case in the OpenType variant too. However, such a default interferes with the fact that the onum feature is one that we explicitly have to enable. This means that writing a generic style where a font is later plugged in becomes somewhat messy if it assumes that features need to be turned on. T E X users expect more control, which means that in practice just an OpenType engine is not enough, but for the average font the T E X model using the traditional approach still is quite acceptable. After all, not all users use complex scripts or need advanced features. And, in practice most readers don’t notice the difference anyway. 1.7 Lua A.7 As mentioned support for virtual fonts is built into LuaT E X and loading the so called vf files happens when needed. However, that concerns traditional fonts that we already covered. In ConT E Xt we do use the virtual font mechanism for creating missing glyphs out of existing ones or add fallbacks when this is not possible. But this is not related to some kind of font format. In 2010 and 2011 the first public OpenType math fonts showed up that replace their Type1 originals. In ConT E Xt we already went forward and created virtual Unicode fonts out of traditional fonts. Of course eventually the defaults will change to the OpenType alternatives. The specification for such a virtual font is given in Lua tables and therefore you can consider Lua to be a font format as well. In ConT E Xt such fonts can be defined in so called goodies files. As we use these files for much more tuning, we come back to that in a later chapter. In a virtual font you can mix real Type1 fonts and real OpenType fonts using whatever metrics suit best. An extreme example is the virtual Unicode Punk font. This font is defined in the METAPOST language (derived from Don Knuths METAFONT sources) where each glyph is one graphic. Normally we get PostScript, but in LuaT E X we can also get output in a
comparable Lua table. That output is converted to pdf literals that become part of the virtual font definitions and these eventually end up in the pdf page stream. So, at the T E X end we have regular (virtual) characters and all T E X needs is their dimensions, but in the pdf each glyph is shown using drawing operations. Of course the now available OpenType variant is more efficient, but it demonstrates the possibilities. 1.8 Files We summarize these formats in the following table where we explain what the file suffixes stand for: tfm This is the traditional T E X font metric file format and it reflects the internal quantities that T E X uses. The internal data structures (in LuaT E X) are an extension of the tfm format. vf This file contains information about how to construct and where to find virtual glyphs and is meant for the backend. With LuaT E X this format gets more known. pk This is the bitmap format used for the first generation of T E X fonts but the typesetter never deals with them. Bitmap files are more or less obselete. ofm This is the Omega variant of the tfm files that caters for larger fonts. ovf This is the Omega variant of the vf. pfb In this file we find the glyph data (outlines) and some basic information about the font, like name-to-index mappings. A differently byte-encoded variant of this format is pfa. afm This file accompanies the pfb file and provides additional metrics, kerns and information about ligatures. A binary variant of this is the pfa format. For MS Windows there is a variant that has the pfm suffix. map The backend will consult this file for mapping metric file names onto real font names. enc The backend will include (and use) this encoding vector to map internal indices to font indices using glyph names, if needed. otf This binary format describes not only the font in terms of metrics, features and properties but also contains the shapes. ttf This is the Microsoft variant of OpenType. ttc This is the Microsoft container format that combines multiple fonts in one. fea A FontForge feature definition file. Such a file can be loaded and applied to a font. cid A glyph index (name) to Unicode mapping file that is referenced from an OpenType font and is shared between fonts. lfg These are ConT E Xt specific Lua font goodie files providing additional information. If you look at how files are organized in a T E X distribution, you will notice that these files all get their own place. Therefore adding a Type1 font to the distribution is not that trivial if you want to avoid clashes. Also, files are simply not found when they are not in the right spot. Just to mention a few paths: 15 Font formats
- Page 1: explaining luatex and mkiv Fonts ou
- Page 4 and 5: 2 Contents 5.4 Goodies 73 5.5 Analy
- Page 6 and 7: 4 Contents
- Page 8 and 9: 6 Introduction In this manual we wi
- Page 10 and 11: 8 Font formats a b g l q . ; ? ffi
- Page 12 and 13: 10 Font formats When T E X ships ou
- Page 14 and 15: 12 A.4 A.3 Font formats multiple ac
- Page 18 and 19: 16 Font formats /fonts/tfm/vendor/t
- Page 20 and 21: 18 Modes raw tfm normalized tfm raw
- Page 22 and 23: 20 Modes shown next: kern cyrl dflt
- Page 24 and 25: 22 Modes ccmp cyrl mkd абвгде
- Page 26 and 27: 24 Modes dlig latn gag abcdefghijkl
- Page 28 and 29: 26 Modes liga latn nsm abcdefghijkl
- Page 30 and 31: 28 Modes salt latn mol abcdefghijkl
- Page 32 and 33: 30 Modes glyph 256 font 42: U+00074
- Page 34 and 35: 32 Modes glyph 256 font 33: U+00061
- Page 36 and 37: 34 Modes glyph 256 font 33: U+00065
- Page 38 and 39: 36 Modes optimizer that can apply a
- Page 40 and 41: 38 Modes ا خLJَ﮲ ف﮲َ step
- Page 42 and 43: 40 Modes dir +TRT glyph 256 font 49
- Page 44 and 45: 42 Modes and now we get: 123 normal
- Page 46 and 47: 44 Modes MkIV run can be faster tha
- Page 48 and 49: 46 Lookups \font \MyFontG = lmr12 s
- Page 50 and 51: 48 Lookups 3.4 Name Say that we wan
- Page 52 and 53: 50 Lookups We add another specifier
- Page 54 and 55: 52 Methods \definefont [MyFont] [Bo
- Page 56 and 57: 54 Methods } copyright = "ConTeXt d
- Page 58 and 59: 56 Features of all, all we get to s
- Page 60 and 61: 58 Features in base mode. A single
- Page 62 and 63: 60 Features accumulate within a wor
- Page 64 and 65: 62 Features features analyze=yes, c
comparable Lua table. That output is converted to pdf literals that become part of the<br />
virtual font definitions and these eventually end up in the pdf page stream. So, at the<br />
T E X end we have regular (virtual) characters and all T E X needs is their dimensions, but<br />
in the pdf each glyph is shown using drawing operations. Of course the now available<br />
OpenType variant is more efficient, but it demonstrates the possibilities.<br />
1.8 Files<br />
We summarize these formats in the following table where we explain what the file<br />
suffixes stand for:<br />
tfm This is the traditional T E X font metric file format and it reflects the internal quantities<br />
that T E X uses. The internal data structures (in LuaT E X) are an extension of<br />
the tfm format.<br />
vf This file contains information about how to construct and where to find virtual<br />
glyphs and is meant for the backend. With LuaT E X this format gets more known.<br />
pk This is the bitmap format used for the first generation of T E X fonts but the typesetter<br />
never deals with them. Bitmap files are more or less obselete.<br />
ofm This is the Omega variant of the tfm files that caters for larger fonts.<br />
ovf This is the Omega variant of the vf.<br />
pfb In this file we find the glyph data (outlines) and some basic information about<br />
the font, like name-to-index mappings. A differently byte-encoded variant of this<br />
format is pfa.<br />
afm This file accompanies the pfb file and provides additional metrics, kerns and information<br />
about ligatures. A binary variant of this is the pfa format. For MS Windows<br />
there is a variant that has the pfm suffix.<br />
map The backend will consult this file for mapping metric file names onto real font<br />
names.<br />
enc The backend will include (and use) this encoding vector to map internal indices to<br />
font indices using glyph names, if needed.<br />
otf This binary format describes not only the font in terms of metrics, features and<br />
properties but also contains the shapes.<br />
ttf This is the Microsoft variant of OpenType.<br />
ttc This is the Microsoft container format that combines multiple fonts in one.<br />
fea A FontForge feature definition file. Such a file can be loaded and applied to a font.<br />
cid A glyph index (name) to Unicode mapping file that is referenced from an OpenType<br />
font and is shared between fonts.<br />
lfg These are ConT E Xt specific Lua font goodie files providing additional information.<br />
If you look at how files are organized in a T E X distribution, you will notice that these<br />
files all get their own place. Therefore adding a Type1 font to the distribution is not that<br />
trivial if you want to avoid clashes. Also, files are simply not found when they are not in<br />
the right spot. Just to mention a few paths:<br />
15<br />
Font formats
Change language