At 03:43 PM 10/9/01 -0500, Ayers, Mike wrote:
> Oooh - a swing and a miss!
No -- a pretty complete misunderstanding of my posting on your part.
The implication of my statements is that rich text support is required at
least at some level of your architecture as soon as you want to go beyond
fairly rudimentary support *even* for the common case of mixing Latin
(English) with Han (Chinese...).
The goal stated in the original submission was to create 'documents'. If
this means high quality publications, then plain-text is not the answer.
At 5:05 PM 10/9/01 -0400, Gary P. Grosso wrote:
>Regarding Asmus' contribution, I would assume that such products use
>different fonts depending on what "block" the character is from, as
>shown, e.g., at:
>http://www.unicode.org/Public/3.0-Update/Blocks-3.txt
>
>Since I don't see any definition at the level of Traditional Chinese
>versus Simplified Chinese in the blocks, I don't see how an
>application could properly switch fonts in this case. Perhaps
>the answer is "it doesn't need to" but I'll admit to being a bit
>skeptical on that point. I'm open to being convinced.
Gary is correct that if you have a (rich) text display engine but
plain-text data, the easiest way to do font bindings is by code point
range. Many browsers are in this situation a lot. However, your font
binding choices get better if you do a little bit of language recognition,
which might well allow you to distinguish between mainland Chinese and
Taiwanese Chinese texts, esp. since the most simplified characters have not
been unified with traditional characters.
Such language recognition (in the Latin context) would allow one to select
fonts that match the local typographical conventions more optimally - there
are definite differences, e.g. in the angle of the acute accent between
French and Polish, but they are slight enough that ignoring them is a
viable option.
Finally, if crude output is all that is desired, the differences in the Han
styles are slight enough that the text remains legible, even if mainland
Chinese is rendered in a non-mainland font. Furthermore, one commonly
allows the user to select a default fontstyle that matches their local
background, and seeing the other language rendered in ones own font tends
to make it more readable. (Printed publications where the same tradeoffs
were made exist as well.)
A./
This archive was generated by hypermail 2.1.2 : Tue Oct 09 2001 - 16:22:10 EDT