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
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
In LuaTEX with ConTEXt MkIV support for traditional Type1 fonts is also simplied: only the<br />
pfb and afm les are needed. Currently we only need tfm les for math fonts but that<br />
will change too. Virtual fonts can be built at runtime and we are experimenting with real<br />
time font generation. Of course lenames are still just as messy and inconsistent as ever,<br />
so other tools are still needed to gure out the real names <strong>of</strong> fonts.<br />
So, what is this OpenType and will it really make TEXies life easier? <strong>The</strong> qualication ‘open’<br />
in OpenType carries several suggestions:<br />
• the format is dened in an open way, everybody can read the specication and what<br />
is said there is clear<br />
• the format is open in the sense that one can add additional features, so there are no<br />
limits and/or limits can be shifted<br />
• there is an open community responsible for the advance <strong>of</strong> this specication and<br />
commercial objectives don't interfere and/or lead to conicts<br />
Is this true or not? Indeed the format is dened in the open although the formal specication<br />
is an expensive document. A free variant is available at the Micros<strong>of</strong>t website but<br />
it takes some effort to turn that into a nicely printable document. What is said there is<br />
quite certainly clear for the developers, but it takes quite some efforts to get the picture.<br />
<strong>The</strong> format is binary so one cannot look into the le and see what happens.<br />
<strong>The</strong> key concept is ‘features’, which boils down to a collection <strong>of</strong> manipulations <strong>of</strong> the text<br />
stream based on rules laid down in the font. <strong>The</strong>se can be simple rules, like ‘replace this<br />
character by its smallcaps variant’ or more complex, like ‘if this character is followed by<br />
that character, replace both by yet another’. <strong>The</strong>re are currently two classes <strong>of</strong> features:<br />
substitutions and (relative) positioning. One can indeed add features so there seem to<br />
be no limits.<br />
<strong>The</strong> specication is a hybrid <strong>of</strong> technologies developed by Micros<strong>of</strong>t and Adobe with<br />
some inuence by Apple. <strong>The</strong>se companies may have conicting interests and therefore<br />
this may inuence the openness.<br />
So, in practice we're dealing with a semi-open format, crippled by a lack <strong>of</strong> documentation<br />
and mostly controlled by some large companies. <strong>The</strong>se characteristics make that<br />
developing support for OpenType is not that trivial. Maybe we should keep in mind that<br />
this font format is used for word processors (no focus on typography), desk top publishing<br />
(which permits in-situ tweaking) and rendering text in graphical user interfaces (where<br />
script and language specic rendering is more important than glyph variants). Depending<br />
on the use features can be ignored, or applied selectively, <strong>of</strong> even compensated.<br />
Anyhow, a font specication is only part <strong>of</strong> the picture. In order to render it useful we<br />
need support in programs that display and typeset text and <strong>of</strong> course we need fonts. And<br />
in order to make fonts, we need programs dedicated to that task too.<br />
224 OpenType: too open?