From: Peter Constable (petercon@microsoft.com)
Date: Mon Mar 07 2005 - 23:49:07 CST
> From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org]
On
> Behalf Of Dean Snyder
> >> 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.
>
> 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,
though.
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
text.
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