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 use
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
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
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:
...
which I think is as faulty as that of people who might claim that,
for example, storing ä for Swedish as a, combining diaeresis
would be incorrect from a user's point of view.
I have no problem at all with ä (precomposed) being equivalent to a,
combining diaeresis. I
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
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 you have been following
the damn'd fools thread. We British resisted Napoleon
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
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]:
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,
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 scripsit:
Well, in either case, the original point falls
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
pronunciation, but I
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
yerushalaiai/aim
which
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
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
yerushalaCanonicalOrderingBlock
- Peter
If inserting an otherwise dummy piece of markup in the middle of a
canonical combining sequence
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 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
website: it is actually
.
- the 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
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 example
]
lworld.com cc: [EMAIL PROTECTED]
Sent by: Subject: Re: Yerushala(y)im - or
Biblical Hebrew: meteg
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's really
going
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
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 matrix which
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
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]
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 what I'm saying. And I have no particular problem with the CGJ
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 to
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 50
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 Hebrew data in the current canonical order would
have stopped
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
allowed by the stability policies) breaks
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 needs to maintain, even in normalized
text.
My point is that there *is* no
data today,
because anyone who has attempted
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...
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 longterm
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,
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.
. 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 correct behavior from
a user's point of view -- even taking
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
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 composition
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 understand,
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 unusable.
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
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
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
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 classes such as the
Hebrew vowels,
and also suggested that users
: 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. Also, I
seem to recall that this gave some people heartburn because CGJ was
not intended
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
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 the
, 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 user not be aware of the
encoding, since it is only
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: Yerushala(y)im - or Biblical Hebrew
This explanation
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
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
developers) time and coding; such a system, far
from affecting a small group of Biblical Hebrew specialists (as claimed by
the proposers), is likely to affect nearly all those who work with Unicode
Hebrew. Tell me if I'm wrong please, but isn't moving characters (however
it's disguised) as much
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.
I find the entire idea with CGJ
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 normalized Unicode plain text)
and
b. a minor political problem (that certain
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 be moved*.
What we have
in Biblical Hebrew cannot be reliably distinguished
in normalized Unicode plain text)
and
b. a minor political problem (that certain communities of Biblical
scholars are badmouthing Unicode because it can't fix its
obvious mistakes)
Changing the combining classes of Hebrew points
, 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, actually), one should be talking about use of U+2060 WORD
JOINER (WJ), rather than U+FEFF ZWNBS in any such new
the Biblical Hebrew points,
a typical query widget might not, so in that instance, you
want a query on patah, hiriq to match the repository store
instance of patah, CGJ, hiriq. Well, format controls and
some other characters (including CGJ) are ordinarily supposed to
be ignored for searching -- unless
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 comment
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
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
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 position classes such as the Hebrew vowels,
and
also
- 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 we use the
ideographic
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
Philippe Verdy wrote on 07/23/2003 10:19:09 PM:
However, its canonical decomposition into COMBINING DIERESIS,
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)
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 Biblical Hebrew.
--Ken
At 11:06 PM 7/23/2003, Paul Nelson
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
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 lists and privately) could
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
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 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
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
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 problems
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
, 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/
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 with Biblical Hebrew
in mind doesn't hurt what
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 do
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,
: [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/2003, Rick McGowan wrote:
A solution with CGJ
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...
Describing what would be the best combining classes can be
tricky for RTL scripts
__
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 on 07/23/2003 09:55:02
AM:
Peter C, I guess
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:
If there's an agreement about what should have been the best
combining
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. I
. So proposing a new
character would simply postpone resolution of the problem for
Biblical Hebrew.
--Ken
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
requirements for Biblical Hebrew neatly met.
And the bonus is this: any other case of mismatch between
required distinctions for ordering of combining marks for
any script, where normalization of the text would result in
collapse of distinctions or unexpected order, can *also*
be dealt
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 cases, to
get
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
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 cases, to
get
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
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,
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 behaviour
It has been claimed that some errors were made in specifying the combining
classes of some of the characters in the Hebrew Points and Punctuation
section (U+05B0 to U+05C4) of the Hebrew block of the Unicode standard.
Could someone please present a list of these errors.
Jony
On 21/07/2003 22:09, Jony Rosenne wrote:
It has been claimed that some errors were made in specifying the combining
classes of some of the characters in the Hebrew Points and Punctuation
section (U+05B0 to U+05C4) of the Hebrew block of the Unicode standard.
Could someone please present a list
classes proposed in this
document are for developers who want to do custom normalisation in a
controlled text processing environment, with all the expected caveats about
the classes being non-standard. A solution that works flawlessly to both
encode and render Biblical Hebrew text is going to take
and render Biblical Hebrew text is going to
take a while (the proposed control character insertion model breaks
current rendering implementations -- not sure why, but I'm looking
into it). In the meantime, we have users who want to work with a
typeface that can correctly render the entire Biblia
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, [...]
This just isn't going to happen, so people should look elsewhere for
solutions. I don't believe UTC could make such a decision and retain any
sort of
At 06:00 PM 7/22/2003, Rick McGowan wrote:
A solution with CGJ has been proposed, which is very general and can be
applied to this and other such situations.
I get the impression that CGJ support is not very high on the list of
things going to be implemented any time soon by the application
At 02:44 PM 7/22/2003, 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, would the custom values that
you have listed there be suitable for a first draft proposal for new
combining classes?
I believe so. Eli
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 can
be
1 - 100 of 231 matches
Mail list logo
