From: Richard Wordingham (richard.wordingham@ntlworld.com)
Date: Sat Mar 18 2006 - 15:14:10 CST
Philippe Verdy wrote:
> From: "Richard Wordingham":
Philippe:
>>> I did not say that. I said that this support was not complete, and not
>>> working for all the announced Indic scripts that are configurable in IE
>>> options. If there's noway to configure it correctly for these scripts,
>>> these options should simply not be there.
Richard:
>> I disagree. Imperfect support may be better than no support.
Philippe:
> Imperfect support that does not repect the language semantic and changes
> the expected visual order is worse than no support at all. It gives users
> the feeling that this is the correct way to enter text that won't
> interoperate correctly with other systems, because users tweak their input
> to match the expected output, but break the standard logical encoding
> order.
Some users might be delighted with a system that worked in the order they
think natural, i.e. entering characters in the order one normally writes
them. :) I don't know about Devanagari, but Thais generally write their
preposed vowels before the consonants. I do know that in Thailand order
reversal is only a text entry issue for minority Indic scripts.
More practically, a Graphite-capable application that could choose a font
for Burmese on the basis of its being Burmese could actually be functional
for displaying Burmese. In this case, for common browsers we're almost but
not quite there -
1) Uniscribe doesn't support Burmese - but will do soon. (Windows XP
capable support?)
2) Deer Park (a Firefox prototype) doesn't give you the option to choose a
font for Burmese - I don't know how to influence its choice between Code2000
(no Graphite) and Padauk (a Graphite font) so I can take advantage of its
Graphite support.
3) IE 6.0 lets you choose a default font - but doesn't support Graphite.
> If there was no support at all, users wouldnothavetoworry about
incorrectly encoded documents,and they could seek for some other third-party
solutions.
TUNE? Hack fonts? People still ask about how to decipher Thai text that's
encoded in something other than TIS-620 and its extensions (e.g.
windows-874) and adaptations (e.g. Unicode).
> I don't expect it to be perfect, as long as there's no risk of incorrect
> interpretation of the encoded and then rendered text (so if a font does
> not have repha forms, or subjoined letters, or if Indic diacritics that
> should be displayed above or below do display after the cluster, it will
> be OK as long asit renders half-forms, or if at least itrenders the base
> consonnant with an explicit virama without the normal half-form or
> ligatures).
> But a font and rendering system that renders a left-matra on the right is
> clearly bogous and generates havoc... It should not be declared compliant,
> and so Unicode should define the minimum acceptable level for rendering
> systems (well, it does, but only in representative glyphs, which are not
> mandatory...so this is not enough.)
How do you suggest a system that doesn't support the script should handle
it? A complete refusal to render it? A hex dump?
> Also, if a font lacks some characters, it MUST signal this absence (and
> must not display an invisible zero-width empty glyph) using a symbol that
> will be represented on the side of the current writing direction (so this
> symbol must be considered BiDi-neutral)...
Actually, the converse is more of an issue - if a character normally has a
visible form, it should not be hidden just because it is in the wrong place
(unless it happens to be obscured by an overstruck character). It's far
from unknown for tone marks to be in the wrong place in Thai (typically
between the consonant and a vowel in the vertical stack) - and then they get
hidden to general confusion. I've fallen foul of this converting from a
legacy Kedmanee-based Thai encodings.
Richard.
This archive was generated by hypermail 2.1.5 : Sat Mar 18 2006 - 15:17:09 CST