[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Devel] Regarding the layout table formats & FreeType 2
From: |
David Turner |
Subject: |
Re: [Devel] Regarding the layout table formats & FreeType 2 |
Date: |
Fri, 26 Mar 2004 22:08:47 +0100 |
User-agent: |
Mozilla Thunderbird 0.5 (Windows/20040207) |
Hi Antoine,
Antoine Leca wrote:
Hi George,
George Williams va escriure:
This may be because GX doesn't really have the range of positioning
possibilities available in OpenType. It has 'kern' and 'opbd' and
that's about it.
Sorry to ask you more contribution: I would like being able to figure it
myself, but my knowledge on GX is simply much too limited.
Can you imagine that every possibility of GX (in this area, i.e. as exposed
by this API) might be implemented on a subsequent OpenType font, decomposing
it into a series of actions dealing with OpenType features?
This is simply not possible. The gap between these two technologies is so
large that they cannot be converted easily into one another, at least in
a general way. Of course, that doesn't mean that a font editor shouldn't be
able to generate both kind of tables from a single higher-level description.
The tables themselves are used in very distinct ways:
- with GX, the client doesn't need to know much about languages
and scripts, because all the information is embedded into the font.
As an example, bi-directionnal text support is coded directly within
the font file (it includes a property table that gives the bidirectionnal
class of every _glyph_ (not character) in the font. This implies that
a working GX layout engine needs a specific BIDI re-ordering algorithm
that doesn't rely on Unicode values.
Another striking difference is the management of features: in AAT/GX, all
features are user-selectable. I won't detail these here though.
- with OpenType Layout, the client must know a _lot_ about scripts
and languages. It must also apply certain features, in specific order,
depending on the current "language" for the run. See the following page
for all the gory details:
http://www.microsoft.com/typography/specs/
look under "Specifications for creating and supporting OpenType Fonts for:"
to retrieve the behaviour of client applications & libraries. It is far
from trivial. By the way, I'm not even sure that Pango's current behaviour
matches the algorithm described in these pages for all scripts (?)
Also "OTL features" are very strange things. Some of them are required by
scripts/languages, while others defined in the feature registry seem to be
user-selectable. It's actually very difficult to tell. And of course,
there's
the atrocious requirement of specifying weird "properties" to glyphs. Huh..
In other words:
GX is:
- hard to implement
- easy to use
- makes font table generation hard (and probably large)
OTL is:
- hard to implement
- hard to use
- makes font table generation easier (and probably shorter)
They're also widely incompatible.
Of course, that's just my opinion. You can also read Dave Opstad's one
at the following address:
http://developer.apple.com/fonts/WhitePapers/GXvsOTLayout.html
If the answer is yes, this may beg to a 2-level API, at the lowest some way
to access the OpenType features and dealing with them, and at an higher
level something that will look like Masatoke's work, whose action would be
direct on a GX font while decomposed in a raw of more "simple" ones in the
case of a OpenType one.
The whole picture might well be attracting, isn't it?
Yes, but it won't be practical. And I guess it will very easily confuse users,
because I suspect that most of them won't be extreme specialists in OTL and GX
:-)
However, if the answer is no, well we are rushing ourselves into David's
option, having two separate APIs (which will certainly make no favour to GX
as a technology)
I prefer that one, unless someone can give me another explanation on how the
technologies work :-(
Regards,
- David Turner
- The FreeType Project (www.freetype.org)
Re: [Devel] Regarding the layout table formats & FreeType 2, Werner LEMBERG, 2004/03/27