Source Browser ?

1% language=us
2
3\startcomponent about-hz
4
5\environment about-environment
6
7\startchapter[title={Font expansion}]
8
9\startsection[title=Introduction]
10
11A lot in \LUATEX\ is not new. It started as a mix of \PDFTEX\ (which itself is
12built on top of original \TEX\ and \ETEX) and the directional bits of \ALEPH\
13(which is a variant of \OMEGA). Of course large portions have been changed in the
14meantime, most noticeably the input encoding (\UNICODE), fonts with a more
15generic fontloader and \LUA\ based processing, \UNICODE\ math and related font
16rendering, and many subsystems can be overloaded or extended. But at the time I
17write this (end of January 2013) the parbuilder still has the \PDFTEX\ font
18expansion code.
19
20This code is the result of a research project by \THANH. By selectively widening
21shapes a better greyness of the paragraph can be achieved. This trick is inspired
22by the work of Hermann Zapf and therefore, instead of expansion, we often talk of
23{\em hz} optimization.
24
25It started with (runtime) generated \METAFONT\ bitmap fonts and as a consequence
26we ended up with many more font instances. However, when eventually bitmap
27support was dropped and outlines became the norm, the implementation didn't
28change much. Also some of the real work was delegated to the backend and as it
29goes then: never change a working system if there's no reason.
30
31When I played with the \LUA\ based par builder I quickly realized that this
32implementation was far from efficient. It was already known that enabling it
33slowed down par building and I saw that this was largely due to many redundant
34calculations, generating auxiliary fonts, and the interaction between front- and
35backend. And, as I seldom hesitate to reimplement something that can be done
36better (one reason why \CONTEXT\ is never finished) I came to an alternative
37implementation. That was 2010. What helped was that by that time Hartmut Henkel
38already had made the backend part cleaner, in the sense that instead of including
39multiple instances of the same font (but with different glyph widths) the base
40font was transformed in|-|line. This made me realize that we could use just one
41font in the frontend and pass the scale with the glyph node to the backend. And
42so, an extra field was added to glyphs nodes in order to make experiments
43possible.
44
45More than two years later (January 2013) I finally took up this pet project and
46figured out how to adapt the backend. Interestingly a few lines of extra code
47we all that was needed. At the same time the frontend part became much simpler,
48that is, in the \LUA\ parbuilder. But eventually it will be retrofitted into the
49core engine, if only because that's much faster.
50
51\stopsection
52
53\startsection[title=The changes]
54
55The most important changes are the following. Instead of multiple font instances,
56only one is used. This way less memory is used, no extra font instances need to
57be created (and those \OPENTYPE\ fonts can be large).
58
59Because less calculations are needed the code looks less complex and more elegant.
60Okay, the parbuilder code will never really look easy, if only because much more
61is involved.
62
63The glyph related factors are related to the emwidth. This makes not much sense
64so in \CONTEXT\ we define them in fractions of the character width, map them onto
65emwidths, and in the parbuilder need to go to glyph related widths again. If we can
66get rid of these emwidths, we have less complex code.
67
68Probably for reasons of efficiency an expanded font carries a definition that
69tells how much stretch and shrink is permitted and how large the steps are. So,
70for instance a font can be widened 5\% and narrowed 3\% in steps of 1\% which
71gives at most 8 extra instances. There is no real reason why this should be a
72font property and the parbuilder cannot deal with fonts with different steps
73anyway, so it makes more sense to make it a property of the paragraph and treat
74all fonts alike. In the \LUA\ based variant we can even have more granularity but
75we leave that for now. In any case this will lift the limitation of mixed font
76usage that is present in the original mechanism.
77
78The front- and backend code with repect to expansion gets clearly separated. In
79fact, the backend doesn't need to do any calculations other than applying the
80factor that is carried with the glyph. This and previously mentioned simplifications
81make the mechanism more efficient.
82
83It is debatable if expansion needs to be applied to font kerns, as is the case in
84the old mechanism. So, at least it should be an option. Removing this feature
85would again made the code nicer. If we keep it, we should keep in mind that
86expansion doesn't work well with complex fonts (say Arabic) but I will look into
87this later. It might be feasible when using the \LUA\ based variant because then
88we can use some of the information that is carried around with the related
89mechanisms. Of course this then related to the \LUA\ based font builder.
90
91\stopsection
92
93\stopchapter
94
95\stopcomponent
96
97