1. Vav Holam may convey two meanings, either just a vowel or a consonant Vav
with the vowel Holam.
Some typographers differentiate these two meaning, many do not. I don't now
if there is any Masoretic basis for the distinction or if it is late, and
whether it is consistently used in those texts t
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
As a proof-of-concept, this would be perfectly valid and reasonably easy to
implement. As a product however, I don't think too many people would go for
it. The group of people who are interested in zero key-travel keyboards (be
they projection, sensor keys, reflection) is pretty finite and I wou
Paul,
This position seems unduly perverse to me, and reflects an
unduly constrained notion of what "not effect the rendering"
means.
First of all, you are clear that CGJ is formally a
combining mark, and not a format control, right?
Second, many of the format controls *do* affect the rendering,
- Original Message -
From: "Peter Kirk" <[EMAIL PROTECTED]>
To: "John Hudson" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 10:40 PM
Subject: Re: Hebrew hataf vowels (was: About CGJ)
> On 24/07/2003 12:18, John Hudson wrote:
>
> > At 11:46 AM 7/24/2003, Peter
This is very interesting.
How about exploring a software solution, based on the projection keyboard concept:
http://www.alpern.org/weblog/stories/2003/01/09/projectionKeyboards.html ?
Cheers,
James
On 24/07/2003 15:27, John Hudson wrote:
At 01:40 PM 7/24/2003, Peter Kirk wrote:
These are display issues, not encoding issues,...
Not entirely. First I need to know what sequence of Unicode
characters I should use to encode holam-waw and aleph with right
holam. Garbage in, garbage out. Then
I have been looking into this for many years and talked to numerous
keyboard manufacturers. While the benefits of such a device are obvious for
multilingual computing, heavily modal software would benefit from it as
well. It appears that the production cost would be too high for most
manufactur
At 01:40 PM 7/24/2003, Peter Kirk wrote:
These are display issues, not encoding issues,...
Not entirely. First I need to know what sequence of Unicode characters I
should use to encode holam-waw and aleph with right holam. Garbage in,
garbage out. Then I need to be sure that your sophisticated r
"Thomas M. Widmann" <[EMAIL PROTECTED]> wrote:
[ . . . ]
> Now, if anybody would manifacture keyboards with tiny LCD displays on
> each key, that problem would disappear, but I have never seen such a
> thing. :-(
This very idea was brought up a few months ago at
http://lists.kabissa.org/lists/arch
On 24/07/2003 12:10, [EMAIL PROTECTED] wrote:
Of course, one of the nasty details in all these suggestions is that, if we
do start using CGJ in the way suggested and also get a new character RIGHT
METEG (for which we need to dream up an appropriate combining class -- pick
a number from 1 to 199!),
On 24/07/2003 12:18, John Hudson wrote:
At 11:46 AM 7/24/2003, Peter Kirk wrote:
One of the specific issues he brought up was this one: how do you
distinguish the holam-waw vowel combination from the consonant waw
followed by the vowel holam?...
These are display issues, not encoding issues,.
Perhaps you could try Microsoft's Keyboard Layout Creator.
--
Joop Jagers (Eindhoven, NL)
\ \\ // /
( @ @ )
oOOO(_)OOOo-
At 15:00 -0400 2003-07-24, John Cowan wrote:
Markus Scherer scripsit:
Note that even for single-language text you may need multiple script
identifiers. For example, for Japanese text you will need 3 identifiers for
Han+Hiragana+Katakana. Obviously, if you have multilingual text, you will
need
Peter Kirk wrote on 07/24/2003 01:10:53 PM:
> Actually I don't need to foresee this, it is
> happening already, as there is already one Hebrew Bible text available
> which displays properly only with Ezra SIL, another which requires
> FrankRuehl, and another which has a different preference. We n
At 11:46 AM 7/24/2003, Peter Kirk wrote:
I'm glad to hear it. But such things need to be cross-platform. They
should also be public*, because that is the only way to make them
cross-platform and because that way we can all be sure that all expert
opinions have been taken into account. So proba
John Hudson wrote on 07/24/2003 12:49:11 PM:
> * Of course, this gets screwed up by Unicode normalisation, but that's
just
> another example of what we've been talking about all along. Personally, I
> would rather see a 'right meteg' character encoded than use CGJ or
another
> mechanism to force
On 24/07/2003 11:17, John Hudson wrote:
The approach I've taken in the SBL Hebrew font is based on extensions
to the current Microsoft Hebrew OpenType spec that Ralph Hancock
worked out in his Unicode/OT versions of the SIL Biblical Hebrew
fonts. Ralph and I corresponded a lot and shared font s
There are many codepages for Indic languages.
Modern systems support Unicode. It is what Windows and MacOS X and Java and modern web browsers etc.
use internally - everything else is supported via conversion, which can be problematic.
The ISCII standard is byte-based and stateful. (Complicated a
At 11:10 AM 7/24/2003, Peter Kirk wrote:
Thanks for the clarification. I hope that at some time soon these things
will be recorded in a proper document, for Unicode and not just for a
particular font. Otherwise I foresee chaos as one font does what you say,
another does not ligate by default bu
On 24/07/2003 10:49, John Hudson wrote:
At 02:34 AM 7/24/2003, Peter Kirk wrote:
... Is this is a valid use of CGJ?
No, this is a valid use of ZWNJ.
This is what currently works:
Left meteg follows vowel (excepting hataf vowel, see below)
Right meteg precedes vowel (including hataf vowel)*
"Michael \(michka\) Kaplan" <[EMAIL PROTECTED]> writes:
> From: "Peter Kirk" <[EMAIL PROTECTED]>
>
> > On 24/07/2003 04:33, [EMAIL PROTECTED] wrote:
>
> > > How to map the code values of the key boards with the code
> > > values for the alphabet given with different Code pages of any
> > > scrip
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 02:34 AM 7/24/2003, Peter Kirk wrote:
There is in fact a similar case in biblical Hebrew, which will need to be
dealt with at some time, and perhaps should be dealt with soon as part of
a comprehensive review of ancient Hebrew support.
The hataf vowels in Hebrew, 05B1-05B3, are graphically c
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 we use the
> ideographic
Alan Wood wrote:
I think this leaves only one character in the old Symbol font that does not
have a Unicode equivalent:
RADICAL EXTENDER (decimal 96 in the Windows version)
When I prepared the proposal for U+23D0 ⏐ VERTICAL LINE EXTENSION, it
was indeed to ensure the complete representation
Alan Wood posted:
I think this leaves only one character in the old Symbol font that does not
have a Unicode equivalent:
RADICAL EXTENDER (decimal 96 in the Windows version)
Or does anyone know where it can be found in Unicode?
Not in Unicode.
Postscript radicalex is an odd character, imaged as
Peter,
> Effectively we'd be looking at some amendment to the normalization
> algorithms to insert CGJ in certain enumerated contexts.
The standard normalization forms (NFC, NFD, NFKC, NFKD) will certainly
not change in this regard.
On the other hand, it would be possible to add additional
distin
For what it's worth, these ISCII code page codes were created by MS for use on
Windows, so my guess would be that these would differ on other platforms.
regards
Cathy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
>
> For those langua
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
From: "Peter Kirk" <[EMAIL PROTECTED]>
> On 24/07/2003 04:33, [EMAIL PROTECTED] wrote:
> > How to map the code values of the key boards with the code values for
> > the alphabet given with different Code pages of any scripts such as
> > devanagari, gujarati etc.
> If you are using Windows, yo
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 24/07/2003 04:33, [EMAIL PROTECTED] wrote:
Dear Forum Members,
I have got some other problems,
We were in the way to develop the multiuser software and I am struck
with the following problems:
How to map the code values of the key boards with the code values for
the alphabet given with
Dear Forum Members,
I have got some other problems,
We were in the way to develop the multiuser
software and I am struck with the following problems:
How to map the code values of the key boards with
the code values for the alphabet given with different Code pages
of any scripts such as
On 23/07/2003 20:19, Philippe Verdy wrote:
There's an interesting case with the
precomposed combining character . Its canonical
decomposition is , and it is excluded from
canonical recomposition (so it is really a *compatibility character*
that should not be present in any normalized form).
Howev
Thanks to Jim and Ken for their replies.
I think this leaves only one character in the old Symbol font that does not
have a Unicode equivalent:
RADICAL EXTENDER (decimal 96 in the Windows version)
Or does anyone know where it can be found in Unicode?
Thank you
Alan Wood
> -Original Messag
38 matches
Mail list logo
