>
Joan, I am a little confused by your response which seems to be out of
order. It seems that I wrote:
>Meteg to the right does not actually need an extra character, because if
>CGJ is used to override canonical equivalence and reordering of vowel
>sequences, the mechanism is already in place to
On 29/07/2003 12:48, [EMAIL PROTECTED] wrote:
Meteg to the right does not actually need an extra character, because if
CGJ is used to override canonical equivalence and reordering of vowel
sequences, the mechanism is already in place to use it in exactly the
same way for sequences of vowels and me
y
says "markup" he means either markup or rich text -- i.e. plain text plus
*something* else. Can we get universal agreement on what that something
else is?
Not to mention the most obvious concern: all this only works in apps that
have been explicitly written to support Biblical Hebrew. That&#
[EMAIL
PROTECTED]>
lworld.com> cc: [EMAIL PROTECTED]
Sent by: Subject: Re: Yerushala(y)im - or
Biblical H
the reason why we appear to be talking past each other.
I agree.
But the implications of keeping the current canonical order are also
staggering. It seems there must be extra rules* for biblical Hebrew which
will have to be written into every keyboard, search engine, and conversion
table.
For
Peter Kirk said:
> So, in my opinion, we do need to make a few small changes so that the
> one encoding is adequate for all Hebrew. If we do these carefully the
> impact on naive Hebrew users will be minimal.
I would hope that the degree of sophistication on the part of the user could
be kept to a
suggestion to encode Biblical Hebrew separately is unacceptable.
A further thought on this one. These principles tend to contradict one
another. The last one, which I strongly support, can only work if the
common encoding for modern and biblical Hebrew is adequate for both.
This means that the
At 04:00 PM 7/28/2003, Peter Kirk wrote:
No. I have no objection to encoding one more meteg character,
as has been proposed, if it is reliably distinguished from
the existing meteg. John Hudson has already argued that
that is enough to enable dealing with the rest of the
rendering distinctions con
takes? I'm not aware of any Biblical scholars badmouthing Unicode: the
ones I know who have heard about Unicode are incredibly enthusiastic about
the prospect of having standardised text interchange for Biblical Hebrew.
The Society of Biblical Literature has been trumpeting Unicode on their
At 11:37 PM 7/28/2003, Jony Rosenne wrote:
Consequently, it was suggested that the several issues with Biblical Hebrew
recently mentioned, and several more which were not, should be solved by
means of markup, outside the scope of Unicode. This is how they have been
addressed in many of the
On 29/07/2003 10:52, [EMAIL PROTECTED] wrote:
A variation (assuming that canonical ordering does not occur around markup
tags), might be something like
yerushala
- Peter
If inserting an otherwise dummy piece of markup in the middle of a
canonical combining sequence does actually reliably
At 06:27 AM 7/29/2003, Ted Hopp wrote:
Based on the SII response, it sounds like either doing nothing (within
Unicode proper) or developing Ken's CGJ proposal are the leading contenders
at this point.
As stated previously, I'm reasonably happy with CGJ as a re-ordering
inhibitor *if* the invisibl
Peter Kirk wrote on 07/29/2003 09:22:35 AM:
> Or is markup
> being suggested as a solution of the Yerushala(y)im issue? If so I fail
> to see how it addresses the problem, as markup does not inhibit
> normalisation.
The markup-based solution would have to be something like
yerushalaim
which wo
Jony Rosenne wrote on 07/29/2003 01:37:00 AM:
> Failing that, it was suggested that an existing Unicode character, such
as
> ZERO WIDTH NO-BREAK SPACE, be used for "invisible" Hebrew letters, in
cases
> such as Yerushala(y)im.
ZWNBSP or any other word-boundary-causing character would give
inappr
ngs of Vav with Holam.
Are we confining "user of Hebrew" to people who know how to speak the
language? If so these people already know how to distinguish the two
meanings of vav with holam because they pronounce them quite
differently. Some users of biblical Hebrew may not know the
ginal Message -
From: "John Cowan" <[EMAIL PROTECTED]>
To: "Karljürgen Feuerherm" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 29, 2003 9:57 AM
Subject: Re: [OT] Metric was Yerushala(y)im - or Biblical Hebrew
> Karljürgen Feuerherm scri
Karljürgen Feuerherm scripsit:
> Well, in either case, the original point falls to bits. Neither of the two
> countries match the original descriptor of 'the at-the-time most progressive
> nation on Earth'.
In terms of reform of this kind, the U.S. certainly does match, thanks to
Thomas Jefferson
Thank you, Jony, for taking this discussion to the SII and for bringing the
response back to this group.
Based on the SII response, it sounds like either doing nothing (within
Unicode proper) or developing Ken's CGJ proposal are the leading contenders
at this point.
Also [inre CGJ and ZWNBSP]:
O
On 28/07/2003 19:05, Kenneth Whistler wrote:
...
This is, of course, precisely the desired result -- the CGJ is
ignored for weighting, but its presence prevents the reordering
of the vowels into the undesired sequence by normalization.
And the resultant weighted key weights the vowels in the corr
;John Cowan" <[EMAIL PROTECTED]>
To: "Peter Kirk" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, July 28, 2003 9:28 PM
Subject: Re: Yerushala(y)im - or Biblical Hebrew
> Peter Kirk scripsit:
>
> > Well, except two countries, or more than two if
On 28/07/2003 18:28, John Cowan wrote:
Peter Kirk scripsit:
Napoleon managed to impose and are still uniform all the way from Calais
to Vladivostok (because even the Russians accepted his system for a
while), even traffic rules (drive on the right, give way to the right),
but are different
Ken Whistler wrote:
...
> which I think is as faulty as that of people who might claim that,
> for example, storing ä for Swedish as
> would be incorrect from a user's point of view.
I have no problem at all with ä (precomposed) being equivalent to . I do have problems with the idea that
shou
Ken Whistler wrote on 07/25/2003 07:39:59 PM:
> > Of course, zwnbs is not a base character...
> There is no need for an invisible base character here.
Moreover, a space of any type would be a particularly bad thing -- it's not
two words.
- Peter
--
Ken Whistler wrote on 07/28/2003 08:34:50 PM:
> I doubt it. I think it is much more likely that the stability of
> normalization per se will hold. And when people finally come to
understand
> that Unicode normalization forms don't meet all of their
> string equivalencing needs, the pressure will
complicated or confuse the common user
- any change or addition to Unicode that would require a user of Hebrew to
have a higher level of knowledge, e.g. to distinguish between items not
commonly distinguished, for example the two meanings of Vav with Holam.
- the suggestion to encode Biblical Hebrew
>On 28 Jul 2003, at 16:49, Kenneth Whistler wrote:
>
> > Part of the specification of the Unicode normalization algorithm
> > is idempotency *across* versions, so that addition of new
> > characters to the standard, which require extensions of the
> > tables for decomposition, recomposition,
Peter Kirk asked:
> One question arises. If CGJ is used as proposed, so we have sequences
> such as patah CGJ hiriq and perhaps meteg CGJ vowel, does this imply
> that these sequences will necessarily be treated in collation as
> distinct from simple patah hiriq and meteg vowel sequences (the l
Ted Hopp scripsit:
> After reading through some of the archives (some pointers to the relevant
> parts would be helpful, please--something beyond "consult the archives"),
The last week or two.
> if umlaut had been a later addition to
> Unicode, no vowel-umlaut code could be allowed to have a de
> After reading through some of the archives (some pointers to the relevant
> parts would be helpful, please--something beyond "consult the archives"), it
> strikes me that normalization, with its severe requirements, is going to
> eventually so distort Unicode that it will render it nearly unusab
Peter Kirk scripsit:
> Well, except two countries, or more than two if you have been following
> the "damn'd fools" thread. We British resisted Napoleon and we continue
> to resist his innovations like the metric system, though we are being
> forced to make a gradual change.
By what I underst
On 28 Jul 2003, at 16:49, Kenneth Whistler wrote:
> Part of the specification of the Unicode normalization algorithm
> is idempotency *across* versions, so that addition of new
> characters to the standard, which require extensions of the
> tables for decomposition, recomposition, and compositi
Okay, Ken. I'm beginning to get it after reading your thoughtful
explanations and after reading through the following two documents (highly
recommended to all following this thread):
http://www.w3.org/TR/WD-charreq
http://www.w3.org/TR/charmod/
After reading through some of the archives (some poi
uld
potentially change normalized data. That is the issue.
Is it a priority for my company that Biblical Hebrew "behave
incorrectly from a user's point of view"? Of course not.
But if yerushala(y)im is "spelled correctly", in this case,
with a CGJ, then implementation of c
At 15:47 -0700 2003-07-28, Peter Kirk wrote:
Well, except two countries, or more than two if you have been
following the "damn'd fools" thread. We British resisted Napoleon
and we continue to resist his innovations like the metric system,
though we are being forced to make a gradual change.
Tha
On 28/07/2003 15:32, Kenneth Whistler wrote:
Joan Wardell responded to:
That's what I'm saying. And I have no particular problem with the CGJ
suggestion, but
it doesn't go far enough. I don't think we can use it to fix meteg, a mark
which occurs in
three different positions around a low vowel,
On Monday, July 28, 2003 5:38 PM, Kenneth Whistler wrote:
> ... And it isn't that nobody
> has longterm vision here, but when one of your goals is
> longterm stability, you have to keep making shortterm decisions
> which individually preserve that stability.
The goal of the Maginot Line was longte
On 28/07/2003 14:37, John Cowan wrote:
Rick McGowan scripsit:
Michael Everson asked:
Do you really think that algorithm with all its warts is going to be
used 50 years from now? I really would like to know.
You want warts, Mr Everson? Well, let's take a look at some history...
at would be considered
by many others to be a fatal flaw in normalization itself.
That is why I have been assiduously promoting an alternate approach
(insertion of CGJ) which does *not* impact normalization, but which
gives Biblical Hebrew a straightforward means of representing
all the distinctions it ne
” ◄
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 28, 2003 14:25
Subject: Re: Yerushala(y)im - or Biblical Hebrew
>
> > Why can't we just fix the database? :)
>
> Because changing the canonical ordering classes (in ways not
>
de 3 and they would have to "start over" if
> we changed the canonical order? And the biggest fear is that the data
> today won't be consistent with the data in the new order? My point
> is that there *is* no data today, because anyone who has attempted
> to produce biblical H
Michael Everson asked:
> >Because changing the canonical ordering classes (in ways not
> >allowed by the stability policies) breaks the normalization
> >*algorithm* and the expected test results it is tested against.
>
> Do you really think that algorithm with all its warts is going to be
> used
Rick McGowan scripsit:
> Michael Everson asked:
>
> > Do you really think that algorithm with all its warts is going to be
> > used 50 years from now? I really would like to know.
>
> You want warts, Mr Everson? Well, let's take a look at some history...
Would the French scientists who set out t
he data today
won't be
consistent with the data in the new order? My point is that there *is* no
data today,
because anyone who has attempted to produce biblical Hebrew data in the
current
canonical order would have stopped and said "Wait a minute! This won't
work".
That's
Michael Everson scripsit:
> Do you really think that algorithm with all its warts is going to be
> used 50 years from now? I really would like to know.
I certainly do.
--
"Clear? Huh! Why a four-year-old childJohn Cowan
could understand this report. Run out [EMAIL PROTECTED
Michael Everson asked:
> Do you really think that algorithm with all its warts is going to be
> used 50 years from now? I really would like to know.
You want warts, Mr Everson? Well, let's take a look at some history...
The standard for e-mail appears to now be RFC 2822, which obsoletes the
ve
At 13:22 -0700 2003-07-28, Kenneth Whistler wrote:
Because changing the canonical ordering classes (in ways not
allowed by the stability policies) breaks the normalization
*algorithm* and the expected test results it is tested against.
Do you really think that algorithm with all its warts is going
r eventual conclusions. ...
>
> I hope you will excuse my ignorance, but I do not understand how correcting
> the canonical classes is such a huge technical problem. If anyone has
> already normalized their biblical Hebrew data, they have trashed it, and it
> will have to be re-done anyway
excuse my ignorance, but I do not understand how correcting
the canonical classes is such a huge technical problem. If anyone has
already normalized their biblical Hebrew data, they have trashed it, and it
will have to be re-done anyway. Secondly, the Character Properties would
appear to be one huge ma
I suspect there are Biblical scholars who would take that
view. I'm simply making a text faithfulness argument.)
K
- Original Message -
From: "Jony Rosenne" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 26, 2003 2:24 AM
Subject: RE: Ye
cal prowess, at best
Biblical literacy.
K
- Original Message -
From: "Jony Rosenne" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 26, 2003 2:27 AM
Subject: RE: Yerushala(y)im - or Biblical Hebrew
> I don't think that it is important that the
On 25/07/2003 23:24, Jony Rosenne wrote:
This explanation makes me unhappy with CGJ.
Ken says: "The important things are that it is a) invisible, b) a combining
mark, and c) has combining class zero".
And: "There is no need for an invisible base character here".
On the contrary, to represent th
On 25/07/2003 17:39, Kenneth Whistler wrote:
...In Unicode 4.0, CGJ has been stripped of all interpretation
except as an invisible mark which can be used to tailor
collation (and searching), so as to distinguish digraphic units
from sequences of the same characters.
Thank you, Ken, for the long
c: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Yerushala(y)im - or Biblical Hebrew
>
>
> Ted continued:
>
> > If I recall correctly, the suggestion for using CGJ for
> yerushala(y)im
> > was to encode it as: <...lamed, patah, cgj, hiriq, final
> mem&
2003 3:50 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Yerushala(y)im - or Biblical Hebrew
>
>
> Peter wrote:
>
> > One thought: Ken has suggested CGJ be used to prevent reordering of
> > combining marks in fixed position c
or type a "CGJ"
key. There are various input and editing strategies to accomplish
this -- effectively the problem is similar to other needs to
tuck hidden characters away in the backing store for bidirectional
text.
The situation for searching is a little different. While the
editing tools m
e be split across
the line at a direct break." U+FEFF retains that semantic, for
backwards compatibility, but its preferred use is as the byte
order mark only.
So whether or not a line break format control character is
relevant to the Biblical Hebrew vowel problem (and I don't think
it is,
and focus on how to minimize whatever damage may be caused by changing
the
> > combining classes.
>
> What we have currently are:
>
> a. a minor technical problem (that certain sequences of vowel
> points in Biblical Hebrew cannot be reliably distinguished
> in normali
It is a violation of the stability policy.
And surely so is the proposal to encode separate vowels for biblical
Hebrew, on the basis that the existing Hebrew vowels are in widespread
use for biblical Hebrew. The stability policy guarantees that "*Once a
character is encoded, it will not
ns' problems
> and focus on how to minimize whatever damage may be caused by changing the
> combining classes.
What we have currently are:
a. a minor technical problem (that certain sequences of vowel
points in Biblical Hebrew cannot be reliably distinguished
in normalize
> To: <[EMAIL PROTECTED]>
> Subject: RE: Yerushala(y)im - or Biblical Hebrew
Kent asserted in response to my comment:
>> Exactly. And frankly, I am finding it difficult to understand
>> why people are characterizing the CGJ proposal as a kludge
>> or an ugly hack.
y're called) that do all that is needed, the choice
seems obvious. Switching to a new, corrected vowel system would save us
(and, I would think, all developers) time and coding; such a system, far
from affecting a small group of Biblical Hebrew specialists (as claimed by
the proposers), i
On 25/07/2003 05:14, Kent Karlsson wrote:
A possible solution to the particular problem at hand that
hasn't yet been mentioned (that I've noticed), is to use the
already encoded vowel characters for the most part (also
for biblical texts), but use new "biblical" vowels only for the
occurrences whe
Kenneth Whistler wrote:
> Exactly. And frankly, I am finding it difficult to understand
> why people are characterizing the CGJ proposal as a kludge
> or an ugly hack. It strikes me as a rather elegant way of
> resolving the problem -- using existing encoded characters and
> existing defined beha
At 06:59 PM 7/24/2003, Kenneth Whistler wrote:
Fourth, even though CGJ itself has no displayable glyph,
and even though it does not serve as a format control for
neighboring characters the way ZWJ and ZWNJ do, it is
clear from John Hudson's discussion that it *does* affect
rendering in an indirect
icult (or irresoluble)
for font designers *is* affecting the rendering.
So I would urge you to think twice, and then maybe again
before unilaterally deciding to remove, based on a
philosophical principle, behavior that makes possible
a straightforward resolution of an otherwise difficult
problem for Bib
Philippe Verdy wrote on 07/23/2003 10:19:09 PM:
> However, its canonical decomposition into COMBINING ACUTE ACCENT> who are both of combining class
> 230 (Above), has an impact in renderers: they are supposed to stack
> one above the other, so the ACUTE ACCENT (oxia, tonos) should
> appear *abov
At 11:06 PM 7/23/2003, Paul Nelson \(TYPOGRAPHY\) wrote:
It is my understanding that the CGJ should not effect the rendering and
is therefore should be removed from the glyphing stream. In the future
the CGJ will not be visible in the rendering process and therefore
should not be counted on to use
- Original Message -
From: "Philippe Verdy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 5:19 AM
Subject: Re: About CGJ (was: Yerushala(y)im - or Biblical Hebrew)
[ ... ]
> If correct placement of diacritics must be specified, could
“Eppur si muove” ◄
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 05:31
Subject: Re: Yerushala(y)im - or Biblical Hebrew
>
> One thought: Ken has suggested CGJ be used to prevent reordering of
> combining marks in fixed posi
On 24/07/2003 05:31, [EMAIL PROTECTED] wrote:
One thought: Ken has suggested CGJ be used to prevent reordering of
combining marks in fixed position classes such as the Hebrew vowels, and
also suggested that users should not need to be aware of the need for CGJ
for this purpose but that software ca
One thought: Ken has suggested CGJ be used to prevent reordering of
combining marks in fixed position classes such as the Hebrew vowels, and
also suggested that users should not need to be aware of the need for CGJ
for this purpose but that software can be implemented in a way that hides
that deta
Jony Rosenne wrote on 07/23/2003 01:43:51 PM:
> With all due respect, this kind of implementation issues is of secondary
> importance. The task of Unicode is to get the encoding right.
I realise that some things that may not work now can be made to work with a
little more effort. But your commen
On Thursday, July 24, 2003 1:24 AM, John Hudson <[EMAIL PROTECTED]> wrote:
> At 03:49 PM 7/23/2003, Peter Kirk wrote:
>
> > (Yerushala(y)im with CGJ) with different versions of Uniscribe (on
> > Windows 2000). In each case CGJ is rendered as a square box in each
> > of several fonts. This behavio
On 23/07/2003 16:24, John Hudson wrote:
As Peter Constable noted, though, we need to be sure that the use of
CGJ in this context is clearly defined and, most importantly, is not
going to conflict with other possible uses. Uniscribe may, in fact,
handle the character in a way that works now, but
At 03:49 PM 7/23/2003, Peter Kirk wrote:
(Yerushala(y)im with CGJ) with different versions of Uniscribe (on Windows
2000). In each case CGJ is rendered as a square box in each of several
fonts. This behaviour indicates that actually Uniscribe treats CGJ as a
regular paintable character, but it
At 03:07 PM 7/23/2003, Kenneth Whistler wrote:
And if the implementers of rendering engines will simply "paint"
instances of U+034F so that they become available to the font
side of the rendering equation, then it should be relatively
simple, as for the Biblical Hebrew point sequence
Peter Kirk wrote on 07/23/2003 09:24:12 AM:
> From Unicode 4.0 section 3.11,
> http://www.unicode.org/book/preview/ch03.pdf: "The particular numeric
> value of the combining class does not have any special significance; the
> intent of providing the numeric values is /only/ to distinguish the
>
On 23/07/2003 15:07, Kenneth Whistler wrote:
And if the implementers of rendering engines will simply "paint"
instances of U+034F so that they become available to the font
side of the rendering equation, then it should be relatively
simple, as for the Biblical Hebrew point sequence cas
s then deal with its default
ignorable status by rendering it with a non-advance, blank glyph
rather than the missing glyph box, then we are in a position to
have both the text processing requirements and the display
requirements for Biblical Hebrew neatly met.
And the bonus is this: any other case
On 23/07/2003 14:18, Mark Davis wrote:
Peter,
This all depends on whether the UTC approves, at the upcoming meeting
in August, the proposal to extend the use of CGJ to allow for
inclusion within sequences of combining marks in order to prevent
reordering of those marks.
Of course, it could be use
nstances of U+034F so that they become available to the font
side of the rendering equation, then it should be relatively
simple, as for the Biblical Hebrew point sequence cases, to
get the sequences to display properly.
> I am now
> wondering if anyone understands what this character is supposed
On 23/07/2003 14:13, Mark Davis wrote:
Exactly. See http://www.unicode.org/faq/normalization.html#8, for
example. (Note: the last FAQ would change if the UTC accepts the
proposal for usage of CGJ.)
Mark
__
http://www.macchiato.com
► “Eppur si muove” ◄
Thank you.
Kirk" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 07:24
Subject: Re: Yerushala(y)im - or Biblical Hebrew
> On 23/07/2003 06:37, [EMAIL PROTECTED] wrote:
>
> >Philippe Verdy wrote on 07/22/2003 09:18:35 PM:
> >
> >
> >
>
__
http://www.macchiato.com
► “Eppur si muove” ◄
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 08:12
Subject: Re: Yerushala(y)im - or Biblical Hebrew
>
> Peter Kirk <[EMAIL PROTECTED]> wrote o
__
http://www.macchiato.com
► “Eppur si muove” ◄
- Original Message -
From: "John Hudson" <[EMAIL PROTECTED]>
To: "Rick McGowan" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 20:34
Subj
03 3:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Yerushala(y)im - or Biblical Hebrew
>
>
>
> Philippe Verdy wrote on 07/22/2003 09:18:35 PM:
>
> > If there's an agreement about what should have been the
> best combining
> > classes...
>
> Descri
age-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of John Hudson
> Sent: Wednesday, July 23, 2003 5:34 AM
> To: Rick McGowan
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: SPAM: Re: Yerushala(y)im - or Biblical Hebrew
>
>
> At 06:00 PM 7/22/200
On 23/07/2003 10:47, Jon Hanna wrote:
should "should" be taken as
giving an obligation or only a recommendation?
I like the way that RFCs have a well defined meaning for "should" or
"recommended" in certain contexts as defined by RFC 2119.
I such contexts these words are taken to mean that
should "should" be taken as
> giving an obligation or only a recommendation?
I like the way that RFCs have a well defined meaning for "should" or
"recommended" in certain contexts as defined by RFC 2119.
I such contexts these words are taken to mean that, while there might be a
valid reason not to
On 23/07/2003 08:12, [EMAIL PROTECTED] wrote:
Unicode does not ever oblige developers to implement support for any given
character, including CGJ. ...
OK. But note that I put "implement" in quotes. The level of
implementation I am looking for is simply to ignore CGJ or delete it
from the rendere
le
> character",
Unicode does not ever oblige developers to implement support for any given
character, including CGJ. But *if* a developer is going to implement
support for CGJ, they may not want to do so just for rendering purposes,
and they probably want to ensure that something done wit
uld be very glad to hear from some of that host of
people, and perhaps to help answer their concerns. But I would be very
surprised if that host is actually as large as the host of those who are
already fighting against the proposal to define separate vowels for
biblical Hebrew.
--
Peter Kirk
[EMAIL PROTECTED]
http://web.onetel.net.uk/~peterkirk/
On 23/07/2003 06:37, [EMAIL PROTECTED] wrote:
Philippe Verdy wrote on 07/22/2003 09:18:35 PM:
If there's an agreement about what should have been the best
combining classes...
Describing what would be the best combining classes can be tricky for RTL
scripts if the canonical ordering is in
Peter Kirk wrote on 07/23/2003 04:40:03 AM:
> I hope you are not suggesting that any application developers are
> prepared to implement changes to support proposals which they have put
> forward to the UTC but are not prepared to implement changes to support
> alternative fixes to the same proble
Philippe Verdy wrote on 07/22/2003 09:18:35 PM:
> If there's an agreement about what should have been the best
> combining classes...
Describing what would be the best combining classes can be tricky for RTL
scripts if the canonical ordering is intended not only for purposes of
normalization and
On 23/07/2003 03:20, Paul Nelson (TYPOGRAPHY) wrote:
Please look at the definition of GCJ and other such characters.
Understand the differences between CGJ and ZWJ/ZWNJ.
This discussion is very disturbing to me because after reading through
the L2 document register it is unclear what is the differ
scholars and Hebrew users
that the proposal to assign separate characters for biblical Hebrew from
modern Hebrew is completely unacceptable.
As for the details of CGJ, please tell me where I can find a detailed
definition, and where it is specifically stated that a *rendering
engine* is obliged
On 22/07/2003 20:49, John Hudson wrote:
Thinking about this whole Hebrew encoding/normalisation problem from
the rendering side -- i.e. in terms of smart font glyph substitution
and mark positioning -- it seems me that *if* a character is to be
inserted between two vowels that visually follow a
fore it attempts any positioning - but not before doing any
normalisation. Of course this doesn't mean that any particular rendering
engine can currently be programmed to do this.
In fact it seems to me that the biblical Hebrew rendering problems which
I have heard about (on various list
On Wednesday, July 23, 2003 3:00 AM, Rick McGowan <[EMAIL PROTECTED]> wrote:
> Peter Kirk wrote:
>
> > And then if (and I know it's a big if) the UTC agrees in principle
> > to allow a change to these combining classes, [...]
>
> A solution with CGJ has been proposed, which is very general and c
1 - 100 of 255 matches
Mail list logo
