Re: Encoded rendering instructions (was Unicode's Mandate)

From: Kenneth Whistler (kenw@sybase.com)
Date: Mon Mar 07 2005 - 19:50:57 CST

  • Next message: Dean Snyder: "Re: Encoded rendering instructions (was Unicode's Mandate)"

    Dean asked:

    > For my purposes I envision a set of nine characters that specify what
    > areas should be subtracted from, or de-emphasized in, the glyph when rendered:

    > The rules for their use are rather simple:

    These rules are *not* simple, from the point of view of a renderer.

    >
    > a) These rendering instruction characters would precede the visible
    > character they modify.

    Conceptually, these are akin to formatting characters, but treated
    as combining marks. They would have to follow, rather than precede
    a base, to fit into rendering models for Unicode.

    > b) Any number of them can be used, disallowing duplicates.

    How would duplicates be disallowed?

    > c} Any order is allowed, with ordering being insignificant.

    This creates equivalence and comparison problems.

    >
    > So I have two questions:
    >
    > 1) What do you think from an encoding point of view?

    I think this is clearly not plain text, and should not be encoded
    this way. As others have suggested, this can and should be handled
    via text markup.

    >
    > 2) Would any of the major text rendering systems even consider
    > implementing such a system if it were encoded?

    I seriously doubt it. Not for plain text.

    > By implement, I mean, for
    > example, in plain text draw all of the letter "A" as normal, except its
    > lower right corner in a lighter shade to indicate damage there.

    That isn't plain text. And to do this kind of thing at all, you
    would need special font support. The very concept of a 3x3 grid
    (or a 2x2 grid, for that matter) doesn't map well, in the general
    case, to rendered glyphs for all writing systems. It already
    assumes a level of abstraction that identifies some square box for
    each glyph to be portrayed in, so that quadrant damage or lacunae
    can be identified. How would I expect a renderer to apply that
    abstraction to Arabic or Mongolian script, for example?

    What *could* be appropriate for encoding as characters, from the
    fields of paleography and epigraphy here, would be entire symbols
    indicating quadrant damage -- in other words, some thematic take on
    sets of quadrant symbols such as U+2596..U+259F, U+25E7, U+25E8,
    U+25F0..U+25F3, etc, which might reflect use in text to *discuss*
    glyph damage and lacunae, etc. This would be quite different from
    trying to encode a bunch of format controls to actually make
    the text *render* with damage and lacunae.

    --Ken



    This archive was generated by hypermail 2.1.5 : Mon Mar 07 2005 - 19:52:18 CST