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 c
Andrew C. West 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 least, most fonts that include any CJK
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 Chines
Rick McGowan wrote:
> Andrew, There isn't a CJK list.
Oops, sorry, I thought there was.
I spent an admittedly brief time looking for a "list of Unicode lists,"
as Rick mentioned, but couldn't find one. I'm sure it's on the Web site
in an obvious place.
-Doug Ewell
Fullerton, California
http
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 man
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 He
> 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 Con
age-
> 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 Hebre
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
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 responded to Michael a few
messages later:
Please keep the
Andrew, There isn't a CJK list.
Rick
> CJK list ? Now if only there was a list of Unicode lists ...
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 ...
Michael Everson 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 responded to Michael a
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
discussion
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
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?
P
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 answering
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.
--
Mi
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: "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 fo
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 "indeciph
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 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
cir
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
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/?_=he&EXPLORE_CollationElements=
ICU implements the UCA, including discontiguous contractions.
Thank you, Markus. Unfortunately the results are barely u
[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
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/?_=he&EXPLORE_CollationElements=
ICU implements the UCA, including discontiguous contractions.
markus
Thank you, Markus. Unfortunately the results are barely usable bec
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 METEG>;
>
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:
I suggest you try it out -
http://oss.software.ibm.com/cgi-bin/icu/lx/en_US/utf-8/?_=he&EXPLORE_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 or
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 l
[I'm not sure why this Hebrew thread has migrated back to the
general Unicode list (from the Hebrew list); but my comments
below aren't specific to Hebrew.]
Jony Rosenne wrote:
...
> > As they will share the same combining class 220, the
> > canonical ordering will preserve their relative order
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:
r 03, 2003 1:37 AM
> To: Jony Rosenne
> 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 th
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 n
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:
T
>
> 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 di
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
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
sa
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 c
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 clas
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
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
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
inten
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
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 wo
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.
> 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
> http://www.qaya.org/a
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
http://scripts.sil.org/cms/sites/nrs
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 ass
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
51 matches
Mail list logo
