- Original Message -
From: Philippe Verdy [EMAIL PROTECTED]
The French names are not the one used by ISO 10646,
For instance :
kannada (English) - kannara (French)
http://pages.infinit.net/hapax/chapitre15.html
http://babel.alis.com/codage/hapax/U32F-0C80.pdf
Sorry, but
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
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
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
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, you might
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
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
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
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
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
- 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
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
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)
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
scripts such as
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)*
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
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
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
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
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
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 need
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
Perhaps you could try Microsoft's Keyboard Layout Creator.
--
Joop Jagers (Eindhoven, NL)
\ \\ // /
( @ @ )
oOOO(_)OOOo-
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
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
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
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
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
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
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
- 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 Kirk wrote:
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,
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
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
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
37 matches
Mail list logo
