John,
You just discovered one more shortcoming of UniScribe. As you say, the
authors did not consider this particular case. I suppose it will be fixed
sooner or later.
I don't see how this affects the discussion, though. UniScribe and most
current fonts do not process the simple case of Holam
At 04:22 -0500 2003-06-27, [EMAIL PROTECTED] wrote:
I just have a hard time believing that 50 years from now our
grandchildren won't look back, What were they thinking? So it took
them a couple of years to figure out canonical ordering and
normalization; why on earth didn't they work that
At 04:22 -0500 2003-06-27, [EMAIL PROTECTED] wrote:
Are we saying that ISO doesn't give a rip for implementation issues?
Duplication of characters is not the way to fix (forgive me, UTC)
*Unicode's* error in combining characters.
Or that their notion of ordering distinctions is different from
At 04:53 -0500 2003-06-27, [EMAIL PROTECTED] wrote:
If they're so unaware of combining classes, might it not seem
reasonable to think the the dialog might continue as follows?
- [gives explanation of combining classes and the related problem for Hebrew]
ISO: So, you're saying you're coming to
Michael Everson scripsit:
Who is it who will kill the Unicode Consortium if UAX #15 were to be
revised? Did it occur to anyone to *ask* about the possible revision
of classes for the dozen or so instances that would be affected?
The IETF, for one. IETF is already very wary of Unicode, even
On Fri, 27 Jun 2003 04:22:30 -0500, [EMAIL PROTECTED] wrote:
I just have a hard time believing that 50 years from now our grandchildren
won't look back, What were they thinking? So it took them a couple of
years to figure out canonical ordering and normalization; why on earth
didn't they
On Friday, June 27, 2003 1:29 PM, John Cowan [EMAIL PROTECTED] wrote:
Michael Everson scripsit:
Change the character classes in Unicode 4.1, and they *might* decide
to freeze support at, say, Unicode 3.0.
Or they may simply opt to define their *OWN* normalization standard, distinct from
Michael Everson scripsit:
Oh, come on. Let's not put words in people's mouths. Ifs and mights
are not facts.
Expressed attitudes are facts, and it's reasonable to extrapolate people's
future behaviors, at least the general trend thereof, from their expressed
attitudes. When someone draws a
At 04:22 -0500 2003-06-27, [EMAIL PROTECTED] wrote:
I just have a hard time believing that 50 years from now our
grandchildren won't look back [...]
I am in complete agreement with the spirit of what Peter says, though
realistically, 50 years from now, this is likely to be all neither here
(Regret I hadn't yet read this post prior to my last post)
Peter said, in reponse to Ken:
Why is it a kludge to insert some cc=0 control character into the text for
the sole purpose of preventing reordering during canonical ordering of two
combining marks that do interact typographically and
On Friday, June 27, 2003 3:23 PM, Karljürgen Feuerherm [EMAIL PROTECTED] wrote:
At 04:22 -0500 2003-06-27, [EMAIL PROTECTED] wrote:
Now, Q: I take it the combining classes are linked to the script,
rather than say to a dialect--e.g. one can't define BH as a separate
dialect from MH with its
Karljürgen Feuerherm scripsit:
1. Everyone is more or less agreed that the present combining class rules as
they apply to BH contain mistakes. The clearly preferential way to deal with
mistakes in any technological/computing software environment is to FIX them.
Not so. Sometimes stability is
At 10:40 -0400 2003-06-27, John Cowan wrote:
Karljürgen Feuerherm scripsit:
1. Everyone is more or less agreed that the present combining class rules as
they apply to BH contain mistakes. The clearly preferential way to deal with
mistakes in any technological/computing software environment is
Michael Everson scripsit:
But you might trot on over with a white flag to parley about a problem.
They're only human beings over there, just as we are over here.
Michael, I *am* the guy carrying the white flag to the W3C, and I have
made promises about what the Unicode Consortium will and
Andrew C. West andrewcwest at alumni dot princeton dot edu wrote:
I have to agree 100% with Peter on this. The potential fiasco with
regards to Mongolian Free Variation Selectors is another area where
our grandchildren are going to be weeping with despair if we are
not careful. The
On Friday, June 27, 2003 4:40 PM, John Cowan [EMAIL PROTECTED] wrote:
Not so. Sometimes stability is more important than correctness.
Very well answered. I don't see why we need to sacrifice stability when
correcting something. As the error is not in ISO10646, it is definitely not
reasonnable
Philippe said on June 27, 2003 at 10:25 AM
On Friday, June 27, 2003 3:23 PM, Karljürgen Feuerherm
[EMAIL PROTECTED] wrote:
I REALLY think that option 1 [FIX the combining classes] should be
beaten to death with a stick,
then beaten to death again, before settling for one of the others.
Do
Philippe Verdy scripsit:
May be Unicode should be more prudent with Normalization Forms: if
new characters are added, their combining classes should be
documented as informative before there is a consensus and
experimentation. This will not break the stability pact with XML, which
will
On Friday, June 27, 2003 5:05 PM, Michael Everson [EMAIL PROTECTED] wrote:
At 10:40 -0400 2003-06-27, John Cowan wrote:
Karljürgen Feuerherm scripsit:
1. Everyone is more or less agreed that the present combining
class rules as they apply to BH contain mistakes. The clearly
On Friday, June 27, 2003 5:53 PM, Karljürgen Feuerherm [EMAIL PROTECTED] wrote:
And in any case this should NOT muck things up which aren't broken,
like MH.
Not breaking Modern Hebrew means not changing the combining classes
of the characters it uses.
Adding a distinct set for Traditional
Karljürgen Feuerherm scripsit:
The use of
the backslash character in DOS/Windows systems as a path separator is
arguably a mistake
I hardly think so. It was a matter of a necessary alternative. It could only
be viewed as a mistake on the assumption that somehow the Unix way was
defacto
Michael Everson scripsit:
No, but you're not making a technical argument, either.
The life of [Unicode] has not been logic but experience.
--Oliver Wendell Holmes, somewhat mutated
Not when their core values -- correctness vs. stability -- are made to
be at odds.
And shifting a
At 02:53 AM 6/27/2003, [EMAIL PROTECTED] wrote:
ISO: Then, obviously they need to correct their errors. I mean, it's not
like the wrong characters got encoded or something. Tell them to just fix
the errors; that can't be difficult to do, and is obviously the right
thing to do.
That seems to be
At 03:12 AM 6/27/2003, Michael Everson wrote:
Who is it who will kill the Unicode Consortium if UAX #15 were to be
revised? Did it occur to anyone to *ask* about the possible revision of
classes for the dozen or so instances that would be affected?
My understanding is that stability promises
John Cowan said on June 27, 2003 at 12:48 PM
Karljürgen Feuerherm scripsit:
Several people have expressed reasons why this can't be
(practically) be
done--which mainly seem to stem from political concerns.
All concerns involving human beings -- ho bios politikos -- are
political
John Hudson scripsit:
What if the request to change the Hebrew combining classes came *from* W3C
and/or IETF? I'm not saying that this is likely, but I'm wondering whether
they might, in fact, not insist on stability for characters for which
normalisation is currently broken anyway?
The
At 05:48 AM 6/27/2003, Michael Everson wrote:
The W3C would also hit the roof if Unicode normalization changed radically.
I don't think anyone is proposing a *radical* change.
I have uploaded the relevant draft pages of the SBL Hebrew user manual to
John Cowan said on June 27, 2003 at 12:56 PM
Michael Everson had said:
This is not analogous to the present situation, it seems to me. In
the first place, what else is the \ for? :-)
Escaping special characters, since you ask.
But in a completely different.
K
John Cowan wrote on 06/27/2003 08:24:35 AM:
The IETF has an explicit contract with Unicode: We'
ll use your normalization algorithm if you promise NEVER, NEVER to
change
the normalization status of a single character. Unicode has already
broken that promise four times, so its credibility is
Philippe Verdy said on June 27, 2003 at 12:38 PM
Subject: Re: Biblical Hebrew (Was: Major Defect in Combining Classes of
Tibetan Vowels)
On Friday, June 27, 2003 5:53 PM, Karljürgen Feuerherm
[EMAIL PROTECTED] wrote:
And in any case this should NOT muck things up which aren't broken,
like
Philippe said on June 27, 2003 at 10:25 AM
Do you then propose to create a specific character, for use within the
Hebrew script only, as a way to specify an alternate order for hebrew
cantillation? In that case, it would be more appropriate to define new
standard variants of these cantillation
(repost. last word missing, sorry)
John Cowan said on June 27, 2003 at 12:56 PM
Michael Everson had said:
This is not analogous to the present situation, it seems to me. In
the first place, what else is the \ for? :-)
Escaping special characters, since you ask.
But in a
Peter replied:
Karljürgen Feuerherm wrote on 06/27/2003 08:23:08 AM:
Now, Q: I take it the combining classes are linked to the script, rather
than say to a dialect
They're linked to the character.
--e.g. one can't define BH as a separate dialect from
MH with its own set of rules?
At 10:20 AM 6/27/2003, John Cowan wrote:
What if the request to change the Hebrew combining classes came *from* W3C
and/or IETF? I'm not saying that this is likely, but I'm wondering whether
they might, in fact, not insist on stability for characters for which
normalisation is currently
Peter responded:
Kenneth Whistler wrote on 06/26/2003 05:36:34 PM:
Why is making use of the existing behavior of existing characters
a groanable kludge, if it has the desired effect and makes
the required distinctions in text?
Why is it a kludge to insert some cc=0 control character
At 12:43 AM 6/26/2003, [EMAIL PROTECTED] wrote:
The problem of combinations of vowels with meteg could be
amenable to a similar approach. OR, one could propose just
one additional meteq/silluq character, to make it possible
to distinguish (in plain text) instances of left-side and
right-side
At 10:09 AM 6/26/2003, [EMAIL PROTECTED] wrote:
The Meteg is a completely different issue. There is a small number
of places
were the Meteg is placed differently. Since it does not behave the same as
the regular Meteg, and is thus visually distinguishable, it should be
possible to add a
How about RLM?
Jony
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Hudson
Sent: Thursday, June 26, 2003 6:36 PM
To: Jony Rosenne
Cc: [EMAIL PROTECTED]
Subject: SPAM: RE: Major Defect in Combining Classes of
Tibetan Vowels (Hebrew)
At
Another consequence is that it separates the sequence into two
combining sequences, not one. Don't know if this is a serious problem,
especially since we are concerned with a limited domain with
non-modern usage, but I wanted to mention it.
Mark
__
Jony took the words right out of my mouth:
How about RLM?
Jony
This already belongs, naturally, in the context of the Hebrew
text handling, which is going to have to handle bidi controls.
Another possibility to consider is U+2060 WORD JOINER, the
version of the zero width non-breaking space
Peter responded:
Ken Whistler wrote on 06/25/2003 06:57:56 PM:
People could consider, for example, representation
of the required sequence:
lamed, qamets, hiriq, final mem
as:
lamed, qamets, ZWJ, hiriq, final mem
So, we want to introduce yet *another* distinct
At 02:45 PM 6/26/2003, Mark Davis wrote:
Another consequence is that it separates the sequence into two
combining sequences, not one. Don't know if this is a serious problem,
especially since we are concerned with a limited domain with
non-modern usage, but I wanted to mention it.
It is a serious
At 03:04 PM 6/26/2003, Kenneth Whistler wrote:
How about RLM?
This already belongs, naturally, in the context of the Hebrew
text handling, which is going to have to handle bidi controls.
Ouch. RLM is not expected to fall between combining marks. Not only does
this not render correctly,
At 15:36 -0700 2003-06-26, Kenneth Whistler wrote:
I now like better the suggestions of RLM or WJ for this.
ZZZT. Thank you for playing.
RLM is for forcing the right behaviour for stops and parentheses and
question marks and so on. Introducing it between two combining
characters in Hebrew
At 03:36 PM 6/26/2003, Kenneth Whistler wrote:
Why is making use of the existing behavior of existing characters
a groanable kludge, if it has the desired effect and makes
the required distinctions in text? If there is not some
rendering system or font lookup showstopper here, I'm inclined
to
Michael wrote:
At 15:36 -0700 2003-06-26, Kenneth Whistler wrote:
I now like better the suggestions of RLM or WJ for this.
ZZZT. Thank you for playing.
RLM is for forcing the right behaviour for stops and parentheses and
question marks and so on. Introducing it between two
John,
At 03:36 PM 6/26/2003, Kenneth Whistler wrote:
Why is making use of the existing behavior of existing characters
a groanable kludge, if it has the desired effect and makes
the required distinctions in text? If there is not some
rendering system or font lookup showstopper here, I'm
At 02:36 PM 6/25/2003, Michael Everson wrote:
Write it up with glyphs and minimal pairs and people will see the problem,
if any. Or propose some solution. (That isn't add duplicate characters.)
Peter Constable has written this up and submitted a proposal to the UTC.
Additional documentation of
At 04:57 PM 6/25/2003, Kenneth Whistler wrote:
And I hate to have to continue being Mr. Negativity on this
list, but I remain unconvinced that the proposed solution
(of cloning 14 Hebrew points and vowels) just to fix an
unpreferred canonical reordering result represents the
sole remaining
John Hudson wrote:
At 02:36 PM 6/25/2003, Michael Everson wrote:
Write it up with glyphs and minimal pairs and people will see the problem,
if any. Or propose some solution. (That isn't add duplicate characters.)
Peter Constable has written this up and submitted a proposal to the UTC.
For example, the alleged problem of the vocalization order of
the Masoretes might be amenable to a much less drastic
solution. People could consider, for example, representation
of the required sequence:
lamed, qamets, hiriq, final mem
as:
lamed, qamets, ZWJ, hiriq, final mem
At 06:22 PM 6/25/2003, Kenneth Whistler wrote:
Even if the ZWJ is stripped by the application before the actual
low-level paint API is called, so that instead of
lamed, qamets, ZWJ, hiriq, final mem
the renderer just sees
lamed, qamets, hiriq, final mem
you still end up with the order you need
52 matches
Mail list logo
