On Wed, 4 Apr 2001, Michael Everson wrote:
> The resolution was taken at the Beijing meeting of WG2.
But that can be broken, can't it? (Look at the Tail Fragment case ;)
> The tail fragment was part of three rather old IBM code tables which
> were all mapped into those nasty presentation forms, and this
> particular glyph fragment was missing, and apparently this is causing
> them problems for data conversion.
I can't understand them. They will also need the other parts, don't they?
The other parts is not in Unicode. (Look at positions 0x77, 0x80, 0x8B,
and 0x8D at the first table at the end of that proposal).
> That, I think, wouldn't be the case for you, even if the character was
> used in a national character set. It's easier to map a logical
> character set one-to-many and many-to-one.
No, we will lose lose round-trip. People will get their files corrupt.
They will not like their character to be replaced by six others. Also,
they may have both encodings (<Rial>, and <Reh><Yeh><Alef><Lam>) in their
files. This is exactly the definition of a compatiblity character...
Please note that while IBM Egypt people can get their programs work right
by simply looking at the previous character and unify them, we cannot do
that. If the convertor sees "Arabic Tail Fragment", and there is a
"Final/Isolated Seen Without Tail" before that, they should convert it to
"Seen+ZWNJ". If they are converting from Unicode, they should convert the
final and isoalted forms of "Seen" to "Final/Isolated Seen Without
Tail+Arabic Tail Fragment". But what should we when a convertor wants to
convert back from Unicode to ISIRI 3342 and sees the sequence of "Reh Yeh
Alef Lam" (or "ZWNJ Reh Yeh Alef Lam ZWNJ")?
> The presentation-based model breaks because they're taking fragments
> and sticking them together.
And we have many character sets in use in Iran (the most common being
Iran-System that is the de facto standard) that unify some presentation
forms but not others (look at
http://developer.sharif.ac.ir/farsiweb/iransystem.txt). So would you
encode them?
> I'm just saying what is LIKELY to be the reaction to such a proposal.
I get the point. Forgive my words. I'm only confused with policies.
> Now, if you consider it a lot more like the peseta or rupee currency
> symbols, and showed a glyph that really didn't look like a word,
> maybe. Can you do a discussion document with scans of price tags,
> printed samples, and so on, showing its unity and narrowness?
How can I do that when I don't believe its unity? I told you about my
personal position. I don't believe it to be a real character: It's not a
real currency symbol, its narrowness can be implemented in higher levels,
it always looks like the word, etc. Even the standard itself used the word
to represent the character in their tables (you can see that from the
attached table).
We only believe it to be a compatiblity character (something like
half-width forms, something like Arabic ligatures, etc).
HCI only wants it because we believe it will be helpful to (usually
governmental) organizations that use ISIRI 3342 in their systems. You can
add to that the ease of implementing the Iranian keyboard on systems with
limited technologies like X.
Also, since we want to create new national standards based on Unicode and
ISO/IEC 10646, some of the committee members will insist that we should be
backward compatible with the existing standards and not leave characters
behind. (That's a hard front to fight in, if only you knew... One of them
still insists on asking for disunifying Persian and Arabic letters!)
> >But at least there's a point in getting the proposal rejected. It will get
> >into the pipeline document so future people won't waste their time...
>
> Mmm.
Don't tell anyone, but I would have possibly vote against it if I was not
acting on behalf of HCI ;)
This archive was generated by hypermail 2.1.2 : Fri Jul 06 2001 - 00:17:15 EDT