Re: Printing and Displaying Dependent Vowels

From: Philippe Verdy (
Date: Fri Mar 26 2004 - 16:51:02 EST

  • Next message: Ernest Cline: "Re: What is the principle?"

    From: "Peter Constable" <>
    > > > What is clear is that there's no way to enable these features
    > explicitly in
    > > plain-text files, if there's no standard format control in Unicode to
    > enable
    > > these OpenType font features. May be these could become new
    > "characters" to
    > > allocate in plane 14?
    > This sounds suspiciously like "courtyard codes". (Wonders to self: Are
    > "Philippe Verdy" and "William Overington" aliases for the same person?
    > :-)

    I can ensure you that this is not the same person (look at the country of origin
    detected in the IP address if you are still not convinced).

    > > What I mean here is that there's currently no defined way to convey in
    > > plain text files the intended rendering "features" that are now common in
    > > OpenType fonts and engines.
    > Nor should there be, any more than there should be ways in plain text to
    > indicate typeface, point size, style, etc. There is a class of
    > representations for such information called "rich text", and such
    > representation has been and will very likely continue to be beyond the
    > scope of plain text.

    Note that I was not speeking strictly about style, but about the way to mark the
    text to allow or disallow some script features. This remains something optional
    for the renderer, and this can be ignored as well without breaking the encoded
    text. What I mean here is a set of format controls which help to the
    interpretation of the text by renderers.

    Yes of course we could define all these at the "rich text" format level (for
    example in CSS if it has such functions to select alternate rendering options).
    But when I look at what OpenType "features" perform (I don't mean the content of
    the associated extra GSUB/GPOS tables which is not what I mean here) it looks
    like they are designed to be used for particular languages or scripts, in a way
    that can be used across multiple font designs.

    So a font may implement a feature and another may not. This looks very similar
    to a sort of meta-tagging within the middle of the text to add semantics to it,
    which can then be used by various renderers and fonts to adapt its style on the

    This was already the case when language tags were added to Unicode. And OpenType
    can now include language-specific features which can be triggered by the
    presence of these tags. But in reality, most font features implemented today are
    not performed at the language level but with a finer grained level after the
    language level). And there's no similar way to tag the text with these features.

    Please don't consider this was a proposal, just a question about the feasibility
    of applications that need to use such script-specific features, as part of their
    regular text processing, without even needing it at the graphic level (when I
    look at some OpentType features, their 4-character labels may become part of the
    text-level processing, without even needing any glyph processing in the
    application using these tags.

    So reread my question (this was not a RFE) like this: are there semantics in
    these feature tags (yes, just the 4-letters IDs of these tags, not the content
    of the GSUB/GPOS tables to which they may be mapped in a specific font) which
    would need a way to represent them as format controls within the plain-text

    I think that such semantic exists for these, which may be used or left unused in
    some presentation by a renderer, but may have its own application for plain-text
    handling (without any glyph processing). I suggested that they may be encoded in
    plane 14, possibly among language tags, but this was just a suggestion if they
    ever need to be encoded somewhere.

    This archive was generated by hypermail 2.1.5 : Fri Mar 26 2004 - 17:26:21 EST