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

From: Peter Constable (
Date: Mon Mar 07 2005 - 23:49:07 CST

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

    > From: []
    > Behalf Of Dean Snyder

    > >> By implement, I mean, for
    > >> example, in plain text draw all of the letter "A" as normal, except
    > >> lower right corner in a lighter shade to indicate damage there.
    > >
    > >That isn't plain text.
    > Well, that's begging the question of what is plain text.

    Whenever anyone suggests that something isn't plain text, one can always
    respond that the question of what is plain text is begged.

    A: "I want characters for A-Z that flash when displayed."
    B: "That isn't plain text."
    A: "Well, that's begging the question..."

    Ken's point is that, after years of working with architecting and
    designing implementations for processing of text, he (and many others)
    would consider this far better handled as rich or marked-up text rather
    than plain text.

    I quite agree with that judgment. This idea has several complications. I
    certainly think it's a good idea that paleographers should have a way to
    convey such information, but not in plain text. The one thing that
    resembles this that I *do* think might be appropriate for plain text is
    the case of a base character that has become illegible due to
    degradation of the document, while there are marks that combine with
    that base that are still identifiable. This goes rather beyond that,

    Some complications:

    - You say that one of these rendering modifier characters would proceed
    the character they modify. How do they interact with combining
    sequences? Are the combining characters? Do they have scope over only
    the immediately adjacent character or over a combining sequence? If the
    latter, what happens if a combining sequence has more than one, e.g.

    < base, R1, mark R2, mark, R3, mark >

    where Rn are various rendering modifiers.

    - It is not at all obvious how these would interact with scripts in
    which the character-glyph mapping is complex and non-linear.

    - You conceive of this as simply having an effect on the rasterized
    image, e.g. in terms of alpha-channel transparency. You cannot expect
    such a thing to get widely implemented -- it would remain something
    found only in special-purpose applications. This would be the case for a
    variety of reasons, starting with people not wanting to tinker with code
    that is widely-deployed, has been fairly stable for some time, is
    functioning as required without problem for millions of users, but the
    changes being requested would involve significant rework of the code and
    would benefit a very limited group of users.

    > But the real need is for sometimes very significant historic character
    > damage to travel everywhere with plain text representations of that

    The information being conveyed is not part of the core, logical text --
    the sequence of character identities -- but is a layer of attributes
    applied to that core text. Representing it in terms of markup would make
    complete sense; on the other hand, it's not clear why there might be a
    need to represent such information in plain text.

    Peter Constable

    This archive was generated by hypermail 2.1.5 : Mon Mar 07 2005 - 23:49:47 CST