The history of luaTEX 2006–2009 / v 0.50 - Pragma ADE
The history of luaTEX 2006–2009 / v 0.50 - Pragma ADE The history of luaTEX 2006–2009 / v 0.50 - Pragma ADE
• Designers (or programmers) may assume that features are applied selectively on a range of input, but in automated workows this may not be applicable. Style designers may come up with specications that cannot be matched due to fonts that have only quick and dirty rules. • Features can be specic for languages and scripts. There are many languages and many scripts and only a few are supported. Some features cover similar aspects (for instance ligatures) and where a specic rendering ends up in the language, script, feature matrix is not beforehand clear. In some sense OpenType fonts are intelligent, but they are not programs. Take for instance the frac feature. When enabled, and when supported in the font, it may result in 1/2 being typeset with small symbols. But what about a/b? or this/that? In principle one can have rules that limit this feature to numerals only or to a simple cases with a few characters. But I have seen fonts that produce garbage when such a feature is applied to the whole text. Okay, so one should apply it selectively. But, if that's the way to go, we could as well have let the typesetting program deal with it and select superior and inferior glyphs from the font. In that case the program can deal with fuzzy situations and we're not dependent on the completeness of rules. In practice, at least for the kind of applications that I have for TEX, I cannot rely on features being implemented correctly. For ages TEXies have been claiming that their documents can be reprocessed for years and years. Of course there are dependencies on fonts and hyphenation patterns, but these are relatively stable. However, in the case of OpenType we have not only shapes, but also rules built in. And rules can have bugs. Because fonts vendors don't provide automated updating as with programs, your own system can be quite stable. However, chances are that different machines have variants with better or worse rules, or maybe even with variants with features deleted. I'm sure that at some time Idris Samawi Hamid of the Oriental TEX project (related to LuaTEX) will report on his experiences with font editors, feature editors, and typesetting engines in the process of making an Arabic font that performs the same way in all systems. Trial and error, rereading the specications again and again, participating in discussions on forums, making special test fonts . . . it's a pretty complex process. If you want to make a font that works okay in many applications you need to test your font with each of them, as the Latin Modern and TEX Gyre font developers can tell you. This brings me to the main message of this chapter. On the one hand we're better of with OpenType fonts: installation is trivial, denitions are easy, and multi-lingual documents are no problem due to the fact that fonts are relatively complete. However, in traditional TEX the user just used what came with the system and most decisions were already made by package writers. Now, with OpenType, users can choose features and this demands some knowledge about what they are, when they are supposed to be used (!), and what limitations they carry. In traditional TEX the options were limited, but now there 226 OpenType: too open?
are many under user control. This demands some discipline. So, what we see is a shift from technology (installing, dening) to application (typography, quality). In ConTEXt this has resulted in additional interfaces, like for instance dynamic feature switching, which decouples features from font denitions. It is already clear that OpenType fonts combined with Unicode input will simplify TEX usage considerably. Also, for macro writers things become easier, but they should be prepared to deal with the shortcomings on both Unicode and OpenType. For instance characters that belong together are not always organized logically in Unicode, which results for instance in math characters being (sort of) all over the place, which in turn means that in TEX characters can be either math or text, which in turn relates to the fonts being used, formatting etc. Als, macro package writers now need to take more languages and related interferences into account, but that's mostly a good thing, because it improves the quality of the output. It will be interesting to see how ten years from now TEX macro packages deal with all the subtleties, exceptions, errors, and user demands. Maybe we will end up with as complex font support as for Type1 with its many encodings. On the other hand, as with all technology, OpenType is not the last word on fonts. OpenType: too open? 227
- Page 178 and 179: ound to fonts (instead of being com
- Page 180 and 181: • TEX primitives Access to and co
- Page 182 and 183: • Open an instance using mplib.ne
- Page 184 and 185: is dened in the les whose names sta
- Page 186 and 187: }, }, ["pen"]={ { ["left_x"]=2.4548
- Page 188 and 189: local tx, ty = p.x_coord, p.y_coord
- Page 190 and 191: \startreusableMPgraphic{test} fill
- Page 192 and 193: vardef textext(expr str) = image (
- Page 194 and 195: local factor = 65536*(7200/7227) fu
- Page 196 and 197: end return t This is a typical exam
- Page 198 and 199: The user interface is downward comp
- Page 200 and 201: key concept. There are few accessib
- Page 202 and 203: \directlua 0 { for i=1,10 do tex.pr
- Page 204 and 205: } end And still it's not okay, sinc
- Page 206 and 207: eason why such code normally is not
- Page 208 and 209: Of course we can discuss until eter
- Page 210 and 211: some text some more When using Co
- Page 212 and 213: and the document itself is processe
- Page 214 and 215: setups and functions are assigned n
- Page 216: using some kind of api and history
- Page 226 and 227: In LuaTEX with ConTEXt MkIV support
- Page 230 and 231: 228 OpenType: too open?
- Page 232 and 233: cannot be grabbed and they make the
- Page 234 and 235: 232 It works!
- Page 236 and 237: when writing the result to le, TEX
- Page 238 and 239: 236 Virtual Reality
- Page 240 and 241: \start \textdir TLT one \bidilro tw
- Page 242 and 243: 240 Getting lost
- Page 244 and 245: using a few arabic fonts, some chin
- Page 246 and 247: The core data structure that we nee
- Page 248 and 249: table can contain information about
- Page 250 and 251: The ConTEXt cross reference mechani
- Page 252 and 253: of them. Each lookup has a detailed
- Page 254 and 255: otf.replacements otf.sequences otf.
- Page 256 and 257: features: analyze=yes, calt=yes, cc
- Page 258 and 259: feature mark, lookup ml_arab_l_16_s
- Page 260 and 261: للِ ه ِ feature init, lo
- Page 262 and 263: features: analyze=yes, calt=yes, cc
- Page 264 and 265: esult: 1: [+TRT] U+6DD: [-TRT]
- Page 266 and 267: 2: [+TRT] U+F01DD: [-TRT] The
- Page 268 and 269: Pro. Dr. Donld E. Knuth feature cal
- Page 270 and 271: 268 Tracking
- Page 272 and 273: The order in which this happens now
- Page 274 and 275: normalizers characters words fonts
- Page 276 and 277: local function hyphenation(head,tai
• Designers (or programmers) may assume that features are applied selectively on a<br />
range <strong>of</strong> input, but in automated workows this may not be applicable. Style designers<br />
may come up with specications that cannot be matched due to fonts that have<br />
only quick and dirty rules.<br />
• Features can be specic for languages and scripts. <strong>The</strong>re are many languages and<br />
many scripts and only a few are supported. Some features cover similar aspects (for<br />
instance ligatures) and where a specic rendering ends up in the language, script,<br />
feature matrix is not beforehand clear.<br />
In some sense OpenType fonts are intelligent, but they are not programs. Take for instance<br />
the frac feature. When enabled, and when supported in the font, it may result<br />
in 1/2 being typeset with small symbols. But what about a/b? or this/that? In principle<br />
one can have rules that limit this feature to numerals only or to a simple cases with a few<br />
characters. But I have seen fonts that produce garbage when such a feature is applied<br />
to the whole text. Okay, so one should apply it selectively. But, if that's the way to go,<br />
we could as well have let the typesetting program deal with it and select superior and<br />
inferior glyphs from the font. In that case the program can deal with fuzzy situations and<br />
we're not dependent on the completeness <strong>of</strong> rules. In practice, at least for the kind <strong>of</strong><br />
applications that I have for TEX, I cannot rely on features being implemented correctly.<br />
For ages TEXies have been claiming that their documents can be reprocessed for years<br />
and years. Of course there are dependencies on fonts and hyphenation patterns, but<br />
these are relatively stable. However, in the case <strong>of</strong> OpenType we have not only shapes,<br />
but also rules built in. And rules can have bugs. Because fonts vendors don't provide<br />
automated updating as with programs, your own system can be quite stable. However,<br />
chances are that different machines have variants with better or worse rules, or maybe<br />
even with variants with features deleted.<br />
I'm sure that at some time Idris Samawi Hamid <strong>of</strong> the Oriental TEX project (related to<br />
LuaTEX) will report on his experiences with font editors, feature editors, and typesetting<br />
engines in the process <strong>of</strong> making an Arabic font that performs the same way in all systems.<br />
Trial and error, rereading the specications again and again, participating in discussions<br />
on forums, making special test fonts . . . it's a pretty complex process. If you want to make<br />
a font that works okay in many applications you need to test your font with each <strong>of</strong> them,<br />
as the Latin Modern and TEX Gyre font developers can tell you.<br />
This brings me to the main message <strong>of</strong> this chapter. On the one hand we're better <strong>of</strong><br />
with OpenType fonts: installation is trivial, denitions are easy, and multi-lingual documents<br />
are no problem due to the fact that fonts are relatively complete. However, in<br />
traditional TEX the user just used what came with the system and most decisions were already<br />
made by package writers. Now, with OpenType, users can choose features and this<br />
demands some knowledge about what they are, when they are supposed to be used (!),<br />
and what limitations they carry. In traditional TEX the options were limited, but now there<br />
226 OpenType: too open?
Change language