Re: Windows Glyph Handling

From: Gregg Reynolds (unicode@arabink.com)
Date: Wed Aug 24 2005 - 10:20:22 CDT

  • Next message: Philippe Verdy: "ISO 639-3 beta input form (was: Questions re ISO-639-1,2,3)"

    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.
    >>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?
    >
    >
    > 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)

    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.

    Anyway, it's clearly incorrect to say that *Open Type* does not support
    glyph reordering - it does, obviously. But it is not a service. By
    analogy, SQL supports joins, whether a particular implementation chooses
    to support them or not. One might say that OpenType glyph reordering
    semantics are not *sufficient* to manage all display/selection issues
    involved in text handling, but I don't think that's true either. It all
    depends on how far an implementation wants to go. Seems to me it should
    be possible to write an OT service provider that could handle all that
    stuff for a client app based solely on the info (policies) in OT tables.

    > 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.

    >
    > Bob
    >



    This archive was generated by hypermail 2.1.5 : Wed Aug 24 2005 - 10:21:49 CDT