From: Gregg Reynolds (email@example.com)
Date: Tue Aug 23 2005 - 16:05:00 CDT
John Hudson wrote:
> Richard Wordingham wrote:
>>> In the OpenType model re-ordering is specifically NOT handled at the
>>> glyph level, but at the character level. This is why it only works
>>> with standard Unicode characters, and not codepoints in what I've
>>> come to regard as the 'Pretty Useless Area'.
>> Do you mean 'OpenType' or something like 'Uniscribe/OpenType' or
> I mean OpenType. The OpenType GSUB and GPOS lookup types are not
> designed for glyph *re-ordering*. There is no mechanism within OpenType
> to say 'take this sequence ABC and rearrange it to ACB'. It is a
> presumption of the format that re-ordering, and other aspects of
> language processing, is done at the (buffered) character level. Both
> Microsoft and Adobe will tell you this. It was a design decision, and
> one that has been discussed in numerous articles, discussion lists,
> conference sessions etc. for the better part of a decade.
Might have been the design intention, but it sure doesn't look like the
result. By my reading, GSUB is quite capable of reordering glyphs.
Looks pretty simple to write GSUB stuff using contextual substitution to
do exactly what you claim can't be done, namely take the character input
ABC and produce a glyph sequence that look like "ACB". Or "CAB", or
"ZYZ", or whatever other glyph sequence the font developer desires. Is
that a misreading? To me it looks like that kind of stuff has nothing
to do with language processing; it's purely formal. That's what makes
OT attractive - language typesetting knowledge can migrate from
application code to the font.
The unfortunate fact is that apparently nobody fully implements GSUB
capabilities, with the possible exception of some Adobe products.
>> There's no mention of re-ordering by Uniscribe (or equivalent) or of
>> breaking into runs by script - Step 0!. You have to read higher level
>> documentation to realise that the characters may be re-ordered (or
>> even changed!) before the font tables can affect them.
> Yes, precisely. Character level re-ordering is not discussed within the
> OpenType spec itself because it is not something that happens within the
> font format. The OT spec also doesn't talk about the need for character
> level analysis of e.g. Arabic text to determine which OTL features
> should be applied to the default glyphs for each character dependent on
> word position and neighbouring characters, because that is not something
> that happens within the font format.
Are you mistaking implementation for design? It seems like it would be
a fairly simple matter to write purely formal GSUB stuff that will shape
Arabic characters properly using contextual substitution. You just have
to look at three characters at a time. The fact that most
implementations don't support contextual substitution fully doesn't
imply there is some sort of requirement that client software must
understand Arabic contextual substitution.
> OpenType fonts are part of larger
> architectures for script and language support, always relying on
> external shaping engines for a variety of functions, whether those
> shaping engines are in Unscribe, ICU, CoolType, etc. The shaping engines
> handle the character end and the font handles the glyph end; between
> them is some kind of generic OTL handler such as Microsoft's OTLS.
Not a requirement, only one possible implementation design. Arabic
shaping logic can be encoded entirely in open type tables, as far as I
This archive was generated by hypermail 2.1.5 : Tue Aug 23 2005 - 16:06:17 CDT