John Hudson wrote:
> At 03:52 PM 6/26/2003, Rick McGowan wrote:
>
> >I'll weigh in to agree with Ken here. The solution of cloning a whole set
> >of these things just to fix combining behavior is, to understate, not quite
> >nice.
>
> No, but would be far from the not nicest thing in Unicode, an
John,
> At 03:36 PM 6/26/2003, Kenneth Whistler wrote:
>
> >Why is making use of the existing behavior of existing characters
> >a "groanable kludge", if it has the desired effect and makes
> >the required distinctions in text? If there is not some
> >rendering system or font lookup showstopper h
1. I agree with Ken about the current lack of precedent for Cfs before
combining marks. Interestingly, that we do have a proposal to do just
that, in
http://www.unicode.org/review/pr-9.pdf
However, note that the whole purpose of putting the Cf after the Ra is
to separate it from the halant, so th
Michael wrote:
> At 15:36 -0700 2003-06-26, Kenneth Whistler wrote:
>
> >I now like better the suggestions of RLM or WJ for this.
>
> ZZZT. Thank you for playing.
>
> RLM is for forcing the right behaviour for stops and parentheses and
> question marks and so on. Introducing it between two
Rick wrote:
> > I now like better the suggestions of RLM or WJ for this.
>
> I'll have to disagree with Ken. I'm not so sure about either of these. I
> don't think anyone has, in the past, considered what conforming or
> non-conforming behavior would be for a RLM or WJ between two combining
At 03:52 PM 6/26/2003, Rick McGowan wrote:
I'll weigh in to agree with Ken here. The solution of cloning a whole set
of these things just to fix combining behavior is, to understate, not quite
nice.
No, but would be far from the not nicest thing in Unicode, and there's a
really good reason for it
At 03:36 PM 6/26/2003, Kenneth Whistler wrote:
Why is making use of the existing behavior of existing characters
a "groanable kludge", if it has the desired effect and makes
the required distinctions in text? If there is not some
rendering system or font lookup showstopper here, I'm inclined
to th
Ken wrote...
> I now like better the suggestions of RLM or WJ for this.
I'll have to disagree with Ken. I'm not so sure about either of these. I
don't think anyone has, in the past, considered what conforming or
non-conforming behavior would be for a RLM or WJ between two combining
marks. T
At 15:36 -0700 2003-06-26, Kenneth Whistler wrote:
I now like better the suggestions of RLM or WJ for this.
ZZZT. Thank you for playing.
RLM is for forcing the right behaviour for stops and parentheses and
question marks and so on. Introducing it between two combining
characters in Hebrew t
At 03:04 PM 6/26/2003, Kenneth Whistler wrote:
> How about RLM?
This already belongs, naturally, in the context of the Hebrew
text handling, which is going to have to handle bidi controls.
Ouch. RLM is not expected to fall between combining marks. Not only does
this not render correctly, Uniscri
At 02:45 PM 6/26/2003, Mark Davis wrote:
Another consequence is that it separates the sequence into two
combining sequences, not one. Don't know if this is a serious problem,
especially since we are concerned with a limited domain with
non-modern usage, but I wanted to mention it.
It is a serious
Peter responded:
> Ken Whistler wrote on 06/25/2003 06:57:56 PM:
>
> > People could consider, for example, representation
> > of the required sequence:
> >
> >
> >
> > as:
> >
> >
>
> So, we want to introduce yet *another* distinct semantic for ZWJ?
Actually, no, I don't. That was just
Jony took the words right out of my mouth:
> How about RLM?
>
> Jony
This already belongs, naturally, in the context of the Hebrew
text handling, which is going to have to handle bidi controls.
Another possibility to consider is U+2060 WORD JOINER, the
version of the zero width non-breaking spa
Another consequence is that it separates the sequence into two
combining sequences, not one. Don't know if this is a serious problem,
especially since we are concerned with a limited domain with
non-modern usage, but I wanted to mention it.
Mark
__
http://www.macchi
That may be what you see. Myself, every time I look at it, I see an orphaned
Hiriq without a consonant. It is normally placed in between the Lamed and
the Mem, to make certain the point isn't missed (a pun).
Jony
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
How about RLM?
Jony
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of John Hudson
> Sent: Thursday, June 26, 2003 6:36 PM
> To: Jony Rosenne
> Cc: [EMAIL PROTECTED]
> Subject: SPAM: RE: Major Defect in Combining Classes of
> Tibetan Vowels (Hebrew)
At 13:23 -0700 2003-06-26, Kenneth Whistler wrote:
Not only is the name likely to change (based on all the issues
already discussed), but it is conceivable that WG2 could decide to
approve it at some other code position instead.
Indeed I will probably propose to move the character on general
pr
Peter replied to Karljürgen:
> Karljürgen Feuerherm wrote on 06/25/2003 08:31:41 PM:
>
> > I was going to suggest something very similar, a ZW-pseudo-consonant of
> some
> > kind, which would force each vowel to be associated with one consonant.
>
> An invisible *consonant* doesn't make sense b
At 14:32 -0400 2003-06-26, John Cowan wrote:
If you are going to discriminate (invidiously) using a computerized
database, using H for Handicapped (or G for Gimp) will do just as well.
Are you going to complain about the various symbols of religion already
encoded on the same grounds?
I am prepari
At 10:09 AM 6/26/2003, [EMAIL PROTECTED] wrote:
> The Meteg is a completely different issue. There is a small number
of places
> were the Meteg is placed differently. Since it does not behave the same as
> the regular Meteg, and is thus visually distinguishable, it should be
> possible to add a
Doug, Peter, and Michael already provided good responses to
this suggestion by William O, but here is a little further
clarification.
> Well, certainly authority would be needed, yet I am suggesting that where a
> few characters added into an established block are accepted, which is what
> is clai
On Thursday, June 26, 2003 8:16 PM, Elisha Berns <[EMAIL PROTECTED]> wrote:
> It would appear from your answer that even after implementing the
> algorithm to search the Unicode block coverage of a font, the actual
> comparison "data", that is which blocks to compare and how many code
> points, is
Elisha Berns asked:
> It would appear from your answer that even after implementing the
> algorithm to search the Unicode block coverage of a font, the actual
> comparison "data", that is which blocks to compare and how many code
> points, is totally undefined. Is there any kind of standard for
>
Elisha Berns scripsit:
> It's odd to think that the old way of using Charset identifiers in fonts
> worked a lot more cleanly for finding fonts matching a language/language
> group. I would think this kind of core issue would be addressed more
> cleanly by the font standard.
Actually it worked b
WHEELCHAIR SYMBOL at least has the virtue of being descriptive of the symbol
rather than of the use and thus potentially more neutral all the way around.
K
- Original Message -
From: "Michael Everson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 26, 2003 2:13 PM
Subject
William Overington scripsit:
> This issue has arisen because of my concern that a particular symbol has
> been labelled as HANDICAPPED SIGN. I hope that the name will be changed to
> WHEELCHAIR SYMBOL.
If you are going to discriminate (invidiously) using a computerized
database, using H for Hand
On Thursday, June 26, 2003 4:13 PM, Andrew C. West <[EMAIL PROTECTED]> wrote:
> On Thu, 26 Jun 2003 14:26:13 +0200, "Philippe Verdy" wrote:
>
> > Isn't there a work-around with the following function (quote from
> > Microsoft MSDN):
> > (with the caveat that you first need to allocate and fill a
Andrew West wrote:
> By looping through the "ranges" array it is possible to determine
exactly
> which
> characters in which Unicode blocks a given font covers (as long as
your
> sofware
> has an array of Unicode blocks and their codepoint ranges).
> As long as your software has an up-to-date li
At 12:09 -0500 2003-06-26, [EMAIL PROTECTED] wrote:
The only meaning that the Standard implies is that the character encoded
at codepoint x represents they symbol of a wheelchair. It does not imply
*anything* about how its usage in juxtaposition with the name of a person
should be interpreted.
Ind
At 13:03 +0100 2003-06-26, William Overington wrote:
Well, certainly authority would be needed, yet I am suggesting that where a
few characters added into an established block are accepted, which is what
is claimed for these characters, there should be a faster route than having
to wait for bulk r
Wow... How on earth did the subject line "Major Defect in Combining
Classes of Tibetan Vowels" turn into a discussion of Biblical Hebrew? At
least, people, if you're going to transmogrify the discussion, please use a
subject line such as "Biblical Hebrew" which someone already was wise
enou
William Overington wrote on 06/26/2003 07:03:12 AM:
> yet I am suggesting that where a
> few characters added into an established block are accepted, which is
what
> is claimed for these characters, there should be a faster route than
having
> to wait for bulk release in Unicode 4.1.
Once both
William Overington wrote on 06/26/2003 06:24:44 AM:
> > the name is simply a unique identifier within the std.
>
> Well, the Standard is the authority for what is the meaning of the
symbol
> when found in a file of plain text. So if the symbol is in a plain text
> file before or after the
Jony Rosenne wrote on 06/26/2003 06:26:02 AM:
> It may look, silly, but it is correct. What you see are letters
according to
> the writing tradition, which does not include a Yod, and vowels
according to
> the reading tradition which does.
I understand that. My point was, you were talking about
At 04:26 AM 6/26/2003, Jony Rosenne wrote:
I don't think we need any new characters, ZERO WIDTH SPACE would do and it
requires no new semantics.
ZERO WIDTH SPACE would screw up search and sort algorithms, I think,
because it is not a control character per se and may not be ignored as desired.
I'
At 12:43 AM 6/26/2003, [EMAIL PROTECTED] wrote:
> The problem of combinations of vowels with meteg could be
> amenable to a similar approach. OR, one could propose just
> one additional meteq/silluq character, to make it possible
> to distinguish (in plain text) instances of left-side and
> right-
William Overington
wrote:
> Well, certainly authority would be needed, yet I am suggesting that
> where a few characters added into an established block are accepted,
> which is what is claimed for these characters, there should be a
> faster route than having to wait for bulk release in Unicode
On Thu, 26 Jun 2003 14:26:13 +0200, "Philippe Verdy" wrote:
> Isn't there a work-around with the following function (quote from Microsoft
> MSDN):
> (with the caveat that you first need to allocate and fill a Unicode string for
> the
> codepoints you want to test, and this can be lengthy if one wa
On Thursday, June 26, 2003 2:26 PM, Philippe Verdy <[EMAIL PROTECTED]> wrote:
I forgot also the probably better function from the Uniscribe library, which processes
strings through a language-dependant shaping algorithm, and can determine appropriate
glyph substitution, or use custom composite f
On Thursday, June 26, 2003 11:50 AM, Andrew C. West <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Jun 2003 21:58:28 -0700, "Elisha Berns" wrote:
>
> > Some weeks back there were a number of postings about software for
> > viewing Unicode Ranges in TrueType fonts and I had a few questions
> > about that
Tom Gewecke wrote as follows.
> My personal idea of an Orwellian nightmare would to have a committee of
"vigilant freedom protectors" evaluating the "political and social
implications of encoding symbols" and passing judgement on whether
particular characters should be encoded and what their names
Peter Constable wrote as follows.
> the name is simply a unique identifier within the std.
Well, the Standard is the authority for what is the meaning of the symbol
when found in a file of plain text. So if the symbol is in a plain text
file before or after the name of a person then the Sta
Michael Everson wrote as follows.
>At 08:44 -0700 2003-06-25, Doug Ewell wrote:
>
>>If it's true that either the UTC or WG2 has formally approved the
character, for a future version of Unicode or a future amendment to 10646,
then I don't see any reason why font makers can't PRODUCE a font with a
g
It may look, silly, but it is correct. What you see are letters according to
the writing tradition, which does not include a Yod, and vowels according to
the reading tradition which does. There are in the Bible other, more extreme
cases.
I don't think we need any new characters, ZERO WIDTH SPACE
On Wed, 25 Jun 2003 21:58:28 -0700, "Elisha Berns" wrote:
> Some weeks back there were a number of postings about software for
> viewing Unicode Ranges in TrueType fonts and I had a few questions about
> that. Most viewers listed seemed to only check the Unicode Range bits of
> the fonts which can
Hi,
For those of you that couldn't attend and were interested in the exhibitor's
panel at the last Unicode conference, a brief summary is now online at:
http://www.unicode.org/iuc/iuc23/showcase-report.html
If you have any comments or feedback on the page, I would be glad to receive
it off-list.
Sourav,
Hi, your question is ambiguous to me.
You seem to be referring to the fullwidth space and other "wide" or
"fullwidth" characters.
For the fullwidth space look at u+3000 ideographic space.
Unicode has other fullwidth characters encoded. Look at the code charts...
hth
tex
souravm wrote:
>
Twenty-fourth Internationalization and Unicode Conference (IUC24)
Unicode, Internationalization, the Web: Powering Global Business
http://www.unicode.org/iuc/iuc24
Karljürgen Feuerherm wrote on 06/25/2003 08:31:41 PM:
> I was going to suggest something very similar, a ZW-pseudo-consonant of
some
> kind, which would force each vowel to be associated with one consonant.
An invisible *consonant* doesn't make sense because the problem involves
more than just
John Hudson wrote on 06/25/2003 06:47:44 PM:
> >This is not. The Unicode Standard makes no assumptions or claims
> >about what the phonological or meaning equivalence of
> >or is for Biblical Hebrew.
>
> But it does make assumptions about the canonical equivalence of the mark
> orders and ,
Ken Whistler wrote on 06/25/2003 06:57:56 PM:
> People could consider, for example, representation
> of the required sequence:
>
>
>
> as:
>
>
So, we want to introduce yet *another* distinct semantic for ZWJ? We've
got one for Indic, another for Arabic, another for ligatures (similar to
Jony Rosenne wrote on 06/26/2003 12:16:22 AM:
> When, in the Bible, one sees two vowels on a given consonant, it isn't
so.
That's silly. When one sees two vowels on a given consonant in the Bible,
it *is* so: the two vowels are written there. It may not correspond to
actual phonology, ie what
Michael Everson wrote on 06/25/2003 04:36:20 PM:
[ re Biblical Hebrew ]
> Write it up with glyphs and minimal pairs and people will see the
> problem, if any. Or propose some solution. (That isn't "add duplicate
> characters".)
The only solution that UTC is willing to consider I have already s
John Cowan wrote on 06/25/2003 03:15:21 PM:
> I don't understand how the current implementation "breaks BH text".
> At worst, normalization may put various combining marks in a
non-traditional
> order, but all alternative orders are canonically equivalent anyway, and
> no (ordinary) Unicode proce
Ken Whistler wrote on 06/25/2003 05:29:59 PM:
> > The point is that hiriq before patah is *not*
> > canonically equivalent to patah before hiriq,
>
> This is true.
>
> > except in the erroneous
> > assumption of the Unicode Standard: the order of vowels makes words
sound
> > different and m
55 matches
Mail list logo
