From: Kent Karlsson [EMAIL PROTECTED]
The problem is that to express the alt 2 as an ICU tailoring I need
an anchor at level 3, which is ignored at levels 1 and 2. I'm not
sure if I can use a punctuation character (ignored at levels 1-3) as
such an anchor, esp. not since punctuation characters
On Thu, 6 Nov 2003 12:51:53 -0500, John Cowan wrote:
IIRC we talked about this a year or so ago, and kicked around the idea that
the Chinese square could be treated as a glyph variant of U+3013 GETA MARK,
which looks quite different but symbolizes the same thing.
I suspect that few Chinese
Andrew C. West andrewcwest at alumni dot princeton dot edu wrote:
And given that most CJK fonts aim to cover both Chinese and Japanese
characters, how would the square missing ideograph glyph and the
Japanese geta mark be differentiated ? By means of variant selectors ?
In the Windows world
At 15:53 -0800 2003-11-05, Doug Ewell wrote:
Gads, how I wish there were a Hebrew-specific list where these
protracted Hebrew-specific discussions could take place.
There is. [EMAIL PROTECTED]
I just unsubscribed from it because I just can't track the volume of
what's being discussed there.
--
On 06/11/2003 02:42, Michael Everson wrote:
There is. [EMAIL PROTECTED]
I just unsubscribed from it because I just can't track the volume of
what's being discussed there.
Understandable, but sad. When new people join a discussion like that
they often have a lot of questions which need
At 04:55 -0800 2003-11-06, Peter Kirk wrote:
We need to work towards some real proposals for improving Hebrew
support, not just chat. But who is going to know about these
proposals and assess them if they are not on the Hebrew list, and if
discussion of Hebrew is not allowed on the main list?
On Wed, 5 Nov 2003 12:24:00 +0100, Philippe Verdy wrote:
The obliterated character needed for paleolitic studies, or to encode any
texts in which the character is not recognizable already exists: isn't it
the REPLACEMENT CHARACTER?
The problem of how to represent missing/obliterated
On 06/11/2003 05:14, Michael Everson wrote:
At 04:55 -0800 2003-11-06, Peter Kirk wrote:
We need to work towards some real proposals for improving Hebrew
support, not just chat. But who is going to know about these
proposals and assess them if they are not on the Hebrew list, and if
Michael Everson everson at evertype dot com wrote:
At 15:53 -0800 2003-11-05, Doug Ewell wrote:
Gads, how I wish there were a Hebrew-specific list where these
protracted Hebrew-specific discussions could take place.
There is. [EMAIL PROTECTED]
I know. I was being facetious.
Peter Kirk
On Thu, 6 Nov 2003 08:30:24 -0800, Doug Ewell wrote:
I can't help thinking that other specialized lists, such as those
for bidi and CJK, were created to resolve this exact type of problem.
CJK list ? Now if only there was a list of Unicode lists ...
Andrew, There isn't a CJK list.
Rick
CJK list ? Now if only there was a list of Unicode lists ...
I agree with you here, Doug. I am copying this to the Hebrew list in the
hope that those on both lists will follow this kind of procedure. Or
does anyone have strong objections?
On 06/11/2003 08:30, Doug Ewell wrote:
...
Peter Kirk peterkirk at qaya dot org responded to Michael a few
messages
Andrew C. West scripsit:
The problem of how to represent missing/obliterated characters in Unicode when
transcribing manuscript/printed texts and inscriptions, etc. has always
perplexed me.
IIRC we talked about this a year or so ago, and kicked around the idea that
the Chinese square could be
-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
Behalf Of Doug Ewell
Sent: Wednesday, November 05, 2003 3:54 PM
To: Unicode Mailing List
Subject: Re: [hebrew] Re: Hebrew composition model, with cantillation
marks
Gads, how I wish there were a Hebrew-specific list where
But we Hebrew experts want our proposals to be reviewed in advance
by
UTC members and others who understand the broad scope of Unicode...
There have been several such people subscribed to the Hebrew list.
Rambling verbose discussions are making some of them leave however.
Peter
Peter
Philippe Verdy wrote at 10:15 PM on Wednesday, November 5, 2003:
If it's not in the written text, it is not implied by the writer.
If this were true, based on the fact that writers wrote very few of them,
we would be faced with the implication that there were very few vowels
indeed in the old
From: Rick McGowan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 06, 2003 6:43 PM
Subject: Re: Hebrew composition model, with cantillation marks
Andrew, There isn't a CJK list.
Rick
CJK normalization at least does not cause so many problems, as ideographs
are not encoded
From: John Hudson [EMAIL PROTECTED]
At 07:20 PM 11/4/2003, Jony Rosenne wrote:
I was thinking we need a zero width non-breaking character. Maybe we mean
the same.
I think Peter and I were thinking of two characters: one spacing and one
zero-width, both non-breaking. Both would be used for
At 03:24 AM 11/5/2003, Philippe Verdy wrote:
The obliterated character needed for paleolitic studies, or to encode any
texts in which the character is not recognizable already exists: isn't it
the REPLACEMENT CHARACTER?
Such base character should be rendered with a spacing glyph (for example a
John Hudson scripsit:
I think this is a typographical decision, so perhaps a glyph issue.
Absolutely.
Personally, there is no way I'd let a rounded box with oblique hatches
anywhere near any scholarly work that I was typesetting. :)
What glyph would you use for indecipherable character?
At 09:55 AM 11/5/2003, John Cowan wrote:
I think this is a typographical decision, so perhaps a glyph issue.
Absolutely.
Personally, there is no way I'd let a rounded box with oblique hatches
anywhere near any scholarly work that I was typesetting. :)
What glyph would you use for
From: Jony Rosenne [EMAIL PROTECTED]
Philippe Verdy wrote:
In fact, even spelling errors are often made on purpose, and
wanted by their authors. What seems a spelling error at one
time often happens to become a normal spelling for these
words (look at the many abreviated forms of
Gads, how I wish there were a Hebrew-specific list where these
protracted Hebrew-specific discussions could take place.
-Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
From: Peter Kirk [EMAIL PROTECTED]
The only issue is the
medial meteg, which can be solved most simply by defining a new medial
meteg character (or variation selector wiith meteg) which always
combines with an adjacent hataf vowel.
According to Chapter 15 of the Unicode Standard:
A
From: Philippe Verdy [EMAIL PROTECTED]
All that can be done is to create a new variation selector for combining
characters. It could be created:
- either within a new generic set of variation selectors for combining
characters (noted CVSn here) to produce sequences like HEBREW POINT
On 03/11/2003 15:26, Markus Scherer wrote:
I suggest you try it out -
http://oss.software.ibm.com/cgi-bin/icu/lx/en_US/utf-8/?_=heEXPLORE_CollationElements=
ICU implements the UCA, including discontiguous contractions.
markus
Thank you, Markus. Unfortunately the results are barely usable
[this should go back to the Hebrew list only...]
But your mention of ignoring non-blocking combining marks when
processing contractions made me look at the newly released
http://www.unicode.org/reports/tr10/. I noticed there for the first
time, maybe because they are there for the first
Peter Kirk wrote:
On 03/11/2003 15:26, Markus Scherer wrote:
I suggest you try it out -
http://oss.software.ibm.com/cgi-bin/icu/lx/en_US/utf-8/?_=heEXPLORE_CollationElements=
ICU implements the UCA, including discontiguous contractions.
Thank you, Markus. Unfortunately the results are barely
On 02/11/2003 21:55, Jony Rosenne wrote:
I don't see any basis for saying now generally considered misguided. Some
people don't like them. Some of the reasons given were based on a
misunderstanding.
Jony
Well, for example Ken Whistler wrote in
http://www.unicode.org/faq/normalization.html:
On 03/11/2003 07:01, Kent Karlsson wrote:
...
However, the UCA does ignore differences between order of
*non-blocking* (**different** non-zero combining classes)
combining marks **when processing contractions**.
...
Kent, thanks for the hint. For the last few weeks I have been
complaining
I suggest you try it out -
http://oss.software.ibm.com/cgi-bin/icu/lx/en_US/utf-8/?_=heEXPLORE_CollationElements=
ICU implements the UCA, including discontiguous contractions.
markus
Peter Kirk wrote:
On 03/11/2003 07:01, Kent Karlsson wrote:
However, the UCA does ignore differences between
As they will share the same combining class 220, the
canonical ordering will preserve their relative order
Although normalization preserves the order of combining marks of the same
class, I think no meaning should be attached to it, for two reasons:
The collation algorithm ignores such
On 02/11/2003 08:37, Jony Rosenne wrote:
As they will share the same combining class 220, the
canonical ordering will preserve their relative order
Although normalization preserves the order of combining marks of the same
class, I think no meaning should be attached to it, for two reasons:
On 02/11/2003 12:00, Jony Rosenne wrote:
I meant the collation order as it applies to Hebrew, of course.
Jony
OK, so you mean not the collation algorithm but the default (DUCET)
collation data for Hebrew. There are still question marks about the
adequacy of this data, and there is a clear
Cc: 'Philippe Verdy'; Unicode
Subject: Re: Hebrew composition model, with cantillation marks
Currently the only such sequences in Hebrew are sequences of
accents and
so of significance for collation only at the lowest level; that is a
consequence of the allocation, now generally
On 30/10/2003 21:15, Mark E. Shoulson wrote:
Peter Kirk wrote:
On 28/10/2003 18:49, Philippe Verdy wrote:
I just finished an Excel speadsheet that shows the Hebrew
composition model,
and all the problems caused by the canonical order of Hebrew
diacritics.
In summary, most problems come from
After careful analysis of the rendering versus canonical ordering problem of
dagesh/rafe/varika after shin/sin dots, and before vowels, I may conclude
that the sil.org proposal is completely not needed for rendering, as the
existing encoding already complies with Biblical Hebrew with exactly the
Folks, we should not be cross-posting on these threads. The Hebrew list
was created to get these long Hebrew threads off the Unicode list; I
think they should stay there.
Peter
Peter Constable
Globalization Infrastructure and Font Technologies
Microsoft Windows Division
Peter Kirk wrote:
On 28/10/2003 18:49, Philippe Verdy wrote:
I just finished an Excel speadsheet that shows the Hebrew composition
model,
and all the problems caused by the canonical order of Hebrew diacritics.
In summary, most problems come from consonnant modifiers which have a
combining
Thank you, Philippe. I include the full text of your posting plus the
attachment for the benefit of those on the Unicode Hebrew list who have
missed out on this. Some of the issues here have already been discussed
on that list. Also I wonder if you have seen
Normally meteg is positioned below and to the left of any other low
centred mark. Less frequently it is positioned to the right of a low
centred mark. But it is always to the left of a low right mark i.e.
yetiv or dehi. It can also be centred within a hataf vowel. In
From: John Hudson [EMAIL PROTECTED]
At 08:17 AM 10/29/2003, Peter Kirk wrote:
Normally meteg is positioned below and to the left of any other low
centred mark. Less frequently it is positioned to the right of a low
centred mark. But it is always to the left of a low right mark i.e. yetiv
or
At 10:26 AM 10/29/2003, Philippe Verdy wrote:
In the sil.org proposal, the medial meteg is missing, but not the right and
left meteg, as they are encoded within the same class and their order is
preserved when attached to a vowel.
It is not missing, per se. It was presumed that the medial meteg
At 10:26 AM 10/29/2003, Philippe Verdy wrote:
The problem I see here is that ZWJ is not intended to create ligatures
between diacritics, only between clusters that would otherwise still be a
single combining sequence.
Normally CGJ would have fitted better there, but this conflicts with the
intent
On 29/10/2003 10:26, Philippe Verdy wrote:
...
The problem I see here is that ZWJ is not intended to create ligatures
between diacritics, only between clusters that would otherwise still be a
single combining sequence.
Normally CGJ would have fitted better there, but this conflicts with the
On 29/10/2003 10:46, John Hudson wrote:
At 10:26 AM 10/29/2003, Philippe Verdy wrote:
The problem I see here is that ZWJ is not intended to create ligatures
between diacritics, only between clusters that would otherwise still
be a
single combining sequence.
Normally CGJ would have fitted better
From: Peter Kirk [EMAIL PROTECTED]
On 29/10/2003 10:46, John Hudson wrote:
While we're about it, we could propose a spacing, non-breaking ELIDED
CHARACTER for use in ketiv/qere where combining marks need to be
applied to empty space within a word.
How would this differ from NBSP? Now if
This is a separate issue (not strictly related to combining classes or
order), related to the current content of the description of the Hebrew
script in the Unicode reference (chapter 8.1)
I see that the description includes the following text:
[quote]
When points and marks are located below the
I just finished an Excel speadsheet that shows the Hebrew composition model,
and all the problems caused by the canonical order of Hebrew diacritics.
In summary, most problems come from consonnant modifiers which have a
combining class higher than vowels or vowel modifiers.
If vowels had been
49 matches
Mail list logo
