1
2
3\startcomponent mkopen
4
5\environment mkenvironment
6
7\chapter {\OPENTYPE: too open?}
8
9In this chapter I will reflect on \OPENTYPE\ from within my
10limited scope and experience. What Im writing next is my personal
11opinion and I may be wrong in many ways.
12
13Until recently installing fonts in a \TEX\ system was not
14something that a novice user could do easily. First of all, the
15number of files involved is large:
16
17\startitemize
18
19\item If it is a bitmap font, then for each size used there is a
20\PK\ file, and this is reflected in the suffix, for instance \type
21{pk300}.
22
23\item If it is an outline font, then there is a \TYPEONE\ file
24with suffix \type {pfb} or sometimes glyphs are taken from
25\OPENTYPE\ fonts (with \type {ttf} or \type {otf} as suffix). In
26the worst case such wide fonts have to be split into smaller ones.
27
28\item Because \TEX\ needs information about the dimensions of the
29glyphs, a metric file is needed; it has the suffix \type {tfm}. There
30is limit of 256 characters per font.
31
32\item If the font lacks glyphs it can be turned into a virtual
33font and borrow glyphs from other fonts; this time the suffix is
34\type {vf}.
35
36\item If no such metric file is present, one can make one from a
37file that ships with the fonts; it has the suffix \type {afm}.
38
39\item In order to include the font in the final file, the backend
40to \TEX\ has to match glyph references to the glyph slots in the
41font file, and for that it needs an encoding vector, for
42historical reasons this is a \POSTSCRIPT\ blob in a file with
43suffix \type {enc}.
44
45\item This whole lot is associated in a map file, with suffix
46\type {map}, which couples metric files to encodings and
47to font files.
48
49\stopitemize
50
51Of course the user also needs \TEX\ code that defines the font,
52but this differs per macro package. If the user is lucky the
53distributions ships with files and definitions of hisher
54favourite fonts, but otherwise work is needed. Font support in
55\TEX\ systems has been complicated by the facts that the first
56\TEX\ fonts were not \ASCII\ complete, that a 256 limit does not
57go well with multilingual typesetting and that most fonts lacked
58glyphs and demanded dropins. Users of \CONTEXT\ could use
59the \type {texfont} program to generate metrics and map file
60for traditional \TEX\ but this didnt limit the number of files.
61
62In modern \TEX\ engines, like \XETEX\ and \LUATEX, less files are
63needed, but even then some expertise is needed to use \TYPEONE\
64fonts. However, when \OPENTYPE\ fonts are used in combination with
65\UNICODE, things become easy. The (one) fontfile needs to be
66put in a location that the \TEX\ engine knows and things
67should work.
68
69In \LUATEX\ with \CONTEXT\ \MKIV\ support for traditional
70\TYPEONE\ fonts is also simplified: only the \type {pfb} and \type
71{afm} files are needed. Currently we only need \type {tfm} files
72for math fonts but that will change too. Virtual fonts can be
73built at runtime and we are experimenting with real time font
74generation. Of course filenames are still just as messy and
75inconsistent as ever, so other tools are still needed to figure
76out the real names of fonts.
77
78So, what is this \OPENTYPE\ and will it really make \TEX ies life
79easier? The qualification \quote {open} in \OPENTYPE\ carries
80several suggestions:
81
82\startitemize
83
84\item the format is defined in an open way, everybody can read the
85specification and what is said there is clear
86
87\item the format is open in the sense that one can add additional
88features, so there are no limits andor limits can be shifted
89
90\item there is an open community responsible for the advance of this
91specification and commercial objectives dont interfere andor lead
92to conflicts
93
94\stopitemize
95
96Is this true or not? Indeed the format is defined in the open
97although the formal specification is an expensive document. A free
98variant is available at the Microsoft website but it takes some
99effort to turn that into a nicely printable document. What is said
100there is quite certainly clear for the developers, but it takes quite
101some efforts to get the picture. The format is binary so one
102cannot look into the file and see what happens.
103
104The key concept is \quote {features}, which boils down to a
105collection of manipulations of the text stream based on rules laid
106down in the font. These can be simple rules, like \quote {replace
107this character by its smallcaps variant} or more complex, like
108\quote {if this character is followed by that character, replace
109both by yet another}. There are currently two classes of features:
110substitutions and (relative) positioning. One can indeed add
111features so there seem to be no limits.
112
113The specification is a hybrid of technologies developed by
114Microsoft and Adobe with some influence by Apple. These
115companies may have conflicting interests and therefore this may
116influence the openness.
117
118So, in practice were dealing with a semiopen format, crippled by
119a lack of documentation and mostly controlled by some large
120companies. These characteristics make that developing support for
121\OPENTYPE\ is not that trivial. Maybe we should keep in mind that
122this font format is used for word processors (no focus on
123typography), desk top publishing (which permits insitu tweaking)
124and rendering text in graphical user interfaces (where script and
125language specific rendering is more important than glyph
126variants). Depending on the use features can be ignored, or
127applied selectively, of even compensated.
128
129Anyhow, a font specification is only part of the picture. In
130order to render it useful we need support in programs that display
131and typeset text and of course we need fonts. And in order to make
132fonts, we need programs dedicated to that task too.
133
134Lets go back for a moment to traditional \TEX. A letter can be
135represented by its standard glyph or by a smallcaps variant. A
136digit can be represented by a shape that sits on the baseline, or
137one that may go below: an oldstyle numeral. Digits can have the
138same width, or be spaced proportionally. There can be special small
139shapes for super and subscripts. In traditional \TEX\ each such
140variant demanded a font. So, say that one wants normal shapes,
141smallcaps and oldstyle, three fonts were needed and this for each
142of the styles normal, bold, italic, etc. Also a font switch is
143needed in order to get the desired shapes.
144
145In an \OPENTYPE\ universe normal, smallcaps and oldstyle shapes
146can be included in one font and they are organized in features. It
147will be clear that this will make things easier for users: if one
148buys a font, there is no longer a need to sort out what file has
149what shapes, there is no longer a reason for reencodings because
150there is no 256 limit, map files are therefore obsolete, etc.
151Only the \TEX\ definition part remains, and even that is easier
152because one file can be used in different combinations of
153features.
154
155One of the side effects of the already mentioned semiopen
156character of the standard is that we cannot be completely sure
157about how features are implemented. Of course one can argue that
158the specification defines what a feature is and how a font should
159obey it, but in practice it does not work out that way.
160
161\startitemize
162
163\item Nobody forces a font designer (or foundry) to implement
164features. And if a designer provides variants, they may be
165incomplete. In the transition from \TYPEONE\ to \OPENTYPE\ fonts
166may even have no features at all.
167
168\item Some advanced features, like fractions, demand extensive
169substitution rules in the font. The completeness may depend on the
170core application the font was made for, or the ambition of the
171programmer who assists the designer, or on the program that is
172used to produce the font.
173
174\item Many of the features are kind of generic, in the sense that
175they dont depend on heuristics in the typesetting program: its
176just rules that need to be applied. However, the typesetting
177program may be written in such a way that it only recognized
178certain features.
179
180\item Some features make assumptions, for instance in the sense
181that they expect the program to figure out what the first character
182of a word is. Other features only work well if the program implements
183the dedicated machinery for it.
184
185\item Features can originate from different vendors and as a
186result programs may interpret them differently. Developers of
187programs may decide only to support certain features, even if
188similar features can be supported out of the box. In the worst
189case a symbiosis between bugs in programs and bugs in fonts
190from the same vendor can lead to pseudo standards.
191
192\item Designers (or programmers) may assume that features are
193applied selectively on a range of input, but in automated
194workflows this may not be applicable. Style designers may come up with
195specifications that cannot be matched due to fonts that have only
196quick and dirty rules.
197
198\item Features can be specific for languages and scripts. There are
199many languages and many scripts and only a few are supported. Some
200features cover similar aspects (for instance ligatures) and where
201a specific rendering ends up in the language, script, feature
202matrix is not beforehand clear.
203
204\stopitemize
205
206In some sense \OPENTYPE\ fonts are intelligent, but they are not
207programs. Take for instance the frac feature. When enabled, and
208when supported in the font, it {\em may} result in 12 being
209typeset with small symbols. But what about ab? or thisthat? In
210principle one can have rules that limit this feature to numerals
211only or to a simple cases with a few characters. But I have seen
212fonts that produce garbage when such a feature is applied to the
213whole text. Okay, so one should apply it selectively. But, if
214thats the way to go, we could as well have let the typesetting
215program deal with it and select superior and inferior glyphs from
216the font. In that case the program can deal with fuzzy situations
217and were not dependent on the completeness of rules. In practice,
218at least for the kind of applications that I have for \TEX, I
219cannot rely on features being implemented correctly.
220
221For ages \TEX ies have been claiming that their documents can be
222reprocessed for years and years. Of course there are dependencies
223on fonts and hyphenation patterns, but these are relatively
224stable. However, in the case of \OPENTYPE\ we have not only
225shapes, but also rules built in. And rules can have bugs.
226Because fonts vendors dont provide automated updating as with
227programs, your own system can be quite stable. However, chances
228are that different machines have variants with better or worse
229rules, or maybe even with variants with features deleted.
230
231Im sure that at some time Idris Samawi Hamid of the Oriental
232\TEX\ project (related to \LUATEX) will report on his experiences
233with font editors, feature editors, and typesetting engines in the
234process of making an Arabic font that performs the same way in all
235systems. Trial and error, rereading the specifications again and
236again, participating in discussions on forums, making special
237test fonts \unknown\ its a pretty complex process. If you want to
238make a font that works okay in many applications you need to test
239your font with each of them, as the Latin Modern and \TEX\ Gyre
240font developers can tell you.
241
242This brings me to the main message of this chapter. On the one
243hand were better of with \OPENTYPE\ fonts: installation is
244trivial, definitions are easy, and multilingual documents are
245no problem due to the fact that fonts are relatively complete.
246However, in traditional \TEX\ the user just used what came with
247the system and most decisions were already made by package
248writers. Now, with \OPENTYPE, users can choose features and this
249demands some knowledge about what they are, when they are supposed
250to be used (!), and what limitations they carry. In traditional
251\TEX\ the options were limited, but now there are many under user
252control. This demands some discipline. So, what we see is a shift
253from technology (installing, defining) to application (typography,
254quality). In \CONTEXT\ this has resulted in additional
255interfaces, like for instance dynamic feature switching, which
256decouples features from font definitions.
257
258It is already clear that \OPENTYPE\ fonts combined with \UNICODE\
259input will simplify \TEX\ usage considerably. Also, for macro
260writers things become easier, but they should be prepared to deal
261with the shortcomings on both \UNICODE\ and \OPENTYPE. For instance
262characters that belong together are not always organized
263logically in \UNICODE, which results for instance in math characters
264being (sort of) all over the place, which in turn means that in \TEX\
265characters can be either math or text, which in turn relates to the fonts
266being used, formatting etc. Als, macro package writers now need to take
267more languages and related interferences into account, but thats mostly
268a good thing, because it improves the quality of the output.
269
270It will be interesting to see how ten years from now \TEX\ macro
271packages deal with all the subtleties, exceptions, errors, and
272user demands. Maybe we will end up with as complex font support as
273for \TYPEONE\ with its many encodings. On the other hand, as with all
274technology, \OPENTYPE\ is not the last word on fonts.
275
276\stopcomponent
277 |