From: Richard Wordingham (richard.wordingham@ntlworld.com)
Date: Wed Aug 24 2005 - 16:36:57 CDT
Gregg Reynolds wrote:
> Bob_Hallissy@sil.org wrote:
>> On 2005-08-23 22:05:00 Gregg Reynolds wrote:
>>>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.
>> Consider a simple font that implemented just one GSUB rule:
>> If you implement GSUB logic to replace ABC with ADE, then the user
>> selects the E glyph and types a character, what code in the underlying
>> text is replaced? (Answer: the one corresponding to glyph C)
>> Using GSUB logic to replace ABC with ACB, then the user selects the B
>> glyph and types a character, what code in the underlying text is replaced
>> now? (Answer: Same as above) Is this what should happen if you are trying
>> to implement reordering? (Answer: No)
In some scripts, e.g. Tamil, clusters can only be edited by deleting from
the right.
A few days ago, Antoine Leca mentioned an interesting example that shows
that what the correct re-ordering is can depend on what ligatures and
half-forms a font has!
> My answer is: it depends. This is not an issue for OpenType, in my
> opinion, but for the implementation of an OT service, whether that
> implementation is located in an application or in some kind of independent
> module.
>
> It's true that a font with contextual substitution rules imposes a burden
> on (application) clients to manage context at some level, but it looks to
> me like that should be reducible to "manage n characters at a time".
>> It was suggested in another message that cursor handling might get
>> "messed up" -- indeed this is the crux of the problem. When people claim
>> that OpenType does not support reordering, it is because of this issue.
>> There is nothing in OpenType that tracks the logical correspondence
>> between glyphs on either side of a rule.
> I'm not sure there should be. OT is not a spec for a management service;
> it's just data.
>> For a font technology to support reordering, the font logic has to be
>> able to instruct the display system what the correspondence between
>> glyphs is. In my examples above, I've got to be able to instruct the
>> system as to whether the correspondence is (using some hypothetical
>> notation based on glyph sequence numbers): (1,2,3) -> (1,2,3) or is it
>> (1,2,3) -> (1,3,2). OpenType provides no such capability.
> Hmmm, I see what you mean, but I don't think that's an issue for the Open
> Type spec. Informing the client of *anything* is beyond the scope of OT -
> it's just a set of tables and rules for looking things up. I don't see
> any reason an OpenType engine could not provide the info you note above -
> all the info is there.
No, it isn't! There is nothing in the substitution definition in the GSUB
table to distinguish substitution from swapping. The GSUB substitution does
*not* support swapping - just replacement, fusion and splitting. While
multiple cursor positions may be defined for a ligature, there is nothing to
say how they correspond to the individual components. The implication is
almost certainly that they are in the order the layout engine had them in
when it started applying look-ups.
Remember also that the issue is not the OpenType engine of choice - it's
whatever OpenType engine your application uses. The really sad fact is that
hack fonts can all too easily be the only practical solution. I think the
odds are high that the easiest way of working in the Saurashtra script will
be, for years after its encoding in Unicode, to encode it in the Malayalam
script.
Richard.
This archive was generated by hypermail 2.1.5 : Wed Aug 24 2005 - 16:38:33 CDT