29.05.2014 Views

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

SHOW MORE
SHOW LESS

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?

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!