Re: Defined Private Use was: SSP default ignorable characters

From: C J Fynn (
Date: Thu Apr 29 2004 - 06:26:14 EDT

  • Next message: C J Fynn: "Re: Defined Private Use was: SSP default ignorable characters"

    "John Hudson" <>

    > John Jenkins wrote:
    > > FWIW, AAT includes an optional 'prop' table which allows people to
    > > associate a number of Unicode properties -- most notably directionality
    > > -- with specific glyphs in a font. It *is* a little weird to do this,
    > > as John says, but it's there.
    > I debated whether to mention the 'prop' table in my message, but decided it
    serves best as
    > an example of the 'awkward fit' to which I referred. The Apple TT reference
    > identifies the 'prop' table as the 'glyph properties table' -- somewhat
    analogous to the
    > OpenType 'gdef' table. The mix of specifically glyph and quasi-character
    properties in the
    > 'prop' table is quite confusing. More to the point, is this table actually
    used by any
    > software?
    > John Hudson


    Many of the Unicode character properties including directionality already seem
    to have as much or more to do with display than they do with data processing
    so they already occupy a grey area.

    In most situations users will need to have a font to display text correctly.
    Including an additional optional table with character properties to sfnt
    files - even though these properties may appear tied to the *initial* glyphs
    which are directly mapped to those PUA codepoints - shouldn't really pose a
    problem. Once any lookups that use glyphs beyond those initial nominal glyphs
    are being processed by the rendering system initial character properties are
    only as relevant as they would be with any other script.

    Fonts are already specified in rich text (and in many situations they can be
    "embedded" in a document). Adding a table with non default PUA character
    properties could provide a reasonably straightforward means for specifying
    those properties without breaking any existing data or application - or coming
    up with a new means e.g an external file which would have to be specifically
    referenced in the data file.

    Of course there would be no compulsion for "smart font" rendering systems to
    actually make use of such a table..

    - Chris

    This archive was generated by hypermail 2.1.5 : Thu Apr 29 2004 - 08:15:28 EDT