Arcane Jill posted:
(A) A proposed character will be rejected if its glyph is identical in
appearance to that of an extant glyph, regardless of its semantic
meaning,
Obviously not.
Unicode encodes characters not glyphs. That particular glyphs of one
character are normally indistinguishable from
Title: RE: What is the principle?
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Jim Allan
> Sent: Friday, March 26, 2004 1:34 PM
> Arcane Jill posted:
>
> > (A) A proposed character will be rejected if its glyph is
> identical in
> > a
> > (D) None of the above
>
> True.
I would like to add to Jim Allan's excellent explanation
here that the relevant coding domain for these decisions
of same or different for encoding a particular character
is the *script* in question.
The first decision that needs to be taken is whether a
part
At 01:33 PM 3/26/2004, Jim Allan wrote:
Arcane Jill posted:
(A) A proposed character will be rejected if its glyph is identical in
appearance to that of an extant glyph, regardless of its semantic
meaning,
Obviously not.
Unicode encodes characters not glyphs. That particular glyphs of one
charac
At 12:10 -0800 2004-03-26, Kenneth Whistler wrote:
Where people seem to get most hung up the first time they encounter
UTC decisions about encoding characters (particularly for scripts,
as opposed to symbol sets) is on these lookalike and/or historical
relation questions. Hence the eternal newb
From: "Arcane Jill" <[EMAIL PROTECTED]>
> Ignoring all compatibility characters; ignoring everything that has gone
> before; and considering only present and future characters (that is,
> characters currently under consideration for inclusion in Unicode, and
> characters which will be under conside
> [Original Message]
> From: Asmus Freytag <[EMAIL PROTECTED]>
>
> There are millions of fonts out there with variations of the zodiac. Font
> shifting would seem to be the correct answer to implement glyph
variations
> there. (A wrong font will ruin the mood, but not change the identity of
th
I think there are reasons for considering the Pluto variants as
different characters (usage for things other than Pluto) but this
needs checking.
--
Michael Everson * * Everson Typography * * http://www.evertype.com
Ernest Cline wrote...
> Consider for example, a font that offered both of the common glyph
> variants of PLUTO. At present, one would be have to be encoded as
> U+2647 and the other as a private use character, say U+E647.
Well, not necessarily. Depending on your system, one of them could just be
At 02:03 PM 3/26/2004, Ernest Cline wrote:
> [Original Message]
> From: Asmus Freytag <[EMAIL PROTECTED]>
>
> There are millions of fonts out there with variations of the zodiac. Font
> shifting would seem to be the correct answer to implement glyph
variations
> there. (A wrong font will ruin the m
On 26/03/2004 13:31, Philippe Verdy wrote:
...
We will probably soon see new characters added to Hebrew because of problems for
the interpretation of Biblic texts, or simply because the currently used
characters can't fit with any other symbol or letters borrowed from other
scripts as they have t
On 26/03/2004 14:12, Michael Everson wrote:
I think there are reasons for considering the Pluto variants as
different characters (usage for things other than Pluto) but this
needs checking.
Perhaps Pluto will no longer need encoding as a sign, as I gather its
status as a planet is now doubtful.
On 26/03/2004 14:03, Ernest Cline wrote:
...
It would be nice tho, if there was something like a Private Variation
Selector.
...
I can also see some advantages in this. The current PUA system allows
private interchange of characters which are completely distinct from
existing characters. Bu
> Perhaps Pluto will no longer need encoding as a sign, as I gather its
> status as a planet is now doubtful. See
> http://news.bbc.co.uk/1/hi/sci/tech/3516952.stm.
Au contraire, astrologists are busy debating the astrological
significance of Quaoar and Sedna:
http://dellhoroscope.com/dellhoro
From: "Kenneth Whistler" <[EMAIL PROTECTED]>
> So the *real* problem for Unicode is who is inventing the
> astrological signs for Quaoar and Sedna and when will the
> character encoding proposal for them be showing up on our
> doorstep. ;-)
You're very right here. And given the very huge amount of
Peter Kirk scripsit:
> Perhaps Pluto will no longer need encoding as a sign, as I gather its
> status as a planet is now doubtful. See
> http://news.bbc.co.uk/1/hi/sci/tech/3516952.stm.
By the same token, the puncta extraordinaria may or may not be accents,
but their status as characters is not
Asmus Freytag scripsit:
> Another drawback is the fact that
> too few systems handle any variation selectors gracefully.
Well, at least they should be easy to handle in fonts: add the selectors
to the font as invisible characters, and then create mandatory ligatures
for the standardized variant
From: "Peter Kirk" <[EMAIL PROTECTED]>
> When I learned French at school we were taught that all French initial
> h's were silent. But I'm sure there is a lot wrong with French as I was
> taught it.
Well it's true that we almost NEVER pronounce any leading h like in English or
German (at least wit
At 05:32 PM 3/26/2004, John Cowan wrote:
Asmus Freytag scripsit:
> Another drawback is the fact that
> too few systems handle any variation selectors gracefully.
Well, at least they should be easy to handle in fonts: add the selectors
to the font as invisible characters, and then create mandatory
Philippe Verdy scripsit:
> The convention used [...] is to mark the dictionnary entries at the
> letter H with a leading asterisk before all words that have an aspirated
> h (of course this is only a "standard" notation in dictionnaries,
> there's no need to use the asterisk in normal texts).
My
Asmus Freytag scripsit:
> This can be tricky esp,. when the user doesn't know a VS is present
> and the font used to view the data doesn't have an alternate glyph.
Well, surely it'll turn into the black blob, or the reversed question
mark, or whatever. It won't just vanish, except in a font whic
At 05:47 PM 3/27/2004, John Cowan wrote:
Asmus Freytag scripsit:
> This can be tricky esp,. when the user doesn't know a VS is present
> and the font used to view the data doesn't have an alternate glyph.
Well, surely it'll turn into the black blob, or the reversed question
mark, or whatever. It
Asmus Freytag wrote,
> Surly not!
Intentional pun, inadvertent one, or Freudian slip?
> Uninterpreted VS characters should *not* turn into black blobs. If we had
> wanted that to happen, we would have coded different characters.
U+E000 COMBINING BLACK BLOB? Censors would probably love it.
>
> [Original Message]
> From: <[EMAIL PROTECTED]>
>
> Asmus Freytag wrote,
>
> > Uninterpreted VS characters should *not* turn into black blobs. If we
had
> > wanted that to happen, we would have coded different characters.
>
> U+E000 COMBINING BLACK BLOB? Censors would probably love it.
>
> > >
John Cowan wrote:
That reminds me. The name of the circumflex accent is obviously
derived from Greek, but its form is not. Is it in fact the degenerate
descendant of the letter "s", does anybody know?
No. When accent marks (probably in fact tone marks) were first applied
(retrospectively) to
From: "Asmus Freytag" <[EMAIL PROTECTED]>
> Variation selectors are not unassigned characters.
And must not be used after unassigned characters as well...
But can we use them after PUAs, to render specific variants of characters in
specialized fonts made for scripts without a current standard?
Or
James Kass,
> U+E000 COMBINING BLACK BLOB? Censors would probably love it.
It is a much more universal solution than the one that the censors really
wanted.
COMBINING EXPLITIVE DELETE
The character would be inserted after all words and delete them if they were
on a proscribed list of forbidden
At 07:53 PM 3/27/2004, [EMAIL PROTECTED] wrote:
> >What does the collation standard say to do with unassigned codepoints
> >anyhow?
>
> Variation selectors are not unassigned characters.
But, they might be regarded as such by any application predating VSs. And,
likewise for any VS sequences appr
Asmus Freytag wrote,
> While applications predating VSs have no choice but to treat them as what
> they are (in that context) i.e. unassigned characters, applications of later
> date have no business treating unapproved VS sequences as unassigned
> *characters*.
>
> The intent of VSs is to mark
Yes. I can verify that (the Irish word for it is 'cuairín', which can only
mean something softly curved).
mg
Scríobh Séamas Ó Brógáin:
>John Cowan wrote:
>
>> That reminds me. The name of the circumflex accent is obviously
>> derived from Greek, but its form is not. Is it in fact the degenerate
On 27/03/2004 17:47, John Cowan wrote:
Asmus Freytag scripsit:
This can be tricky esp,. when the user doesn't know a VS is present
and the font used to view the data doesn't have an alternate glyph.
Well, surely it'll turn into the black blob, or the reversed question
mark, or whatever.
Ernest Cline stated:
> The standard is quite clear that if a Variation Selector is recognized, but
> not
> the sequence it is, then it should be treated the same as if no selector was
> present.
Which is true.
>
> This is one reason why transferring some or all of the Variation Selectors
> on t
On 29/03/2004 11:28, Kenneth Whistler wrote:
...
Third, the proposal to "transfer ... some or all of the Variation
Selectors on the SSP to Private Use" is unclear on the concept of
Private Use. The UTC will make *no* semantic encoding commitment
regarding what a private use character is to be use
Peter Kirk responded:
> >Third, the proposal to "transfer ... some or all of the Variation
> >Selectors on the SSP to Private Use" is unclear on the concept of
> >Private Use. The UTC will make *no* semantic encoding commitment
> >regarding what a private use character is to be used for. That woul
> [Original Message]
> From: Kenneth Whistler <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Date: 3/29/2004 2:28:25 PM
> Subject: Re: What is the principle?
>
> Ernest Cline stated:
>
> >
> Unicode would benefit from having ranges of Private Use
> characters that would be known to have certain character
> properties, such as being a Variation Selector, or to take
> a topic from a recent thread, if there were Private Use
> characters with a default strong RTL property for the
> Bidir
On 29/03/2004 15:14, Kenneth Whistler wrote:
Peter Kirk responded:
Third, the proposal to "transfer ... some or all of the Variation
Selectors on the SSP to Private Use" is unclear on the concept of
Private Use. The UTC will make *no* semantic encoding commitment
regarding what a private use c
> >They do not. A user of PUA characters is free to define the
> >whole range of PUA characters as consisting of strong R-to-L
> >characters and implementing accordingly. ...
>
> This is not true! Users can define only those properties which the
> software that they are using allows them to defin
"Dominikus Scherkl (MGW)" writes:
> I would expect any application to allow _all_ properties to
be
> defined by the user for each and any PUA charakter.
> If not so, it's a bug in the application! (at least if it can
> handle charakters with the same properties elsewhere in the
Unicode.)
D Starner wrote:
> But in practice I don't know of a single
> program that allows you to change the properties of Unicode
> characters without a recompile.
It's been a while since I've programmed with Apple's Cocoa environment,
but when last I looked, it dynamically loaded the property tables a
At 13:52 -0800 2004-03-30, Rick McGowan wrote:
If there is a real need for exchanging some bunch of symbols, people
should be trying to standardize them, not standardize ways of *not*
standardizing them.
The Klingons are going to be back.
--
Michael Everson * * Everson Typography * * http://www
On 30/03/2004 13:29, D. Starner wrote:
"Dominikus Scherkl (MGW)" writes:
I would expect any application to allow _all_ properties to
be
defined by the user for each and any PUA charakter.
If not so, it's a bug in the application! (at least if it can
handle charakters with the same
Rick McGowan <[EMAIL PROTECTED]> writes:
> It was written that way on purpose.
That's a nice solution that I wish more systems had adopted.
> "Unicode" has never written any platform software, so it
> could hardly have made the PUA "too hard to use".
There's two private use planes.
Peter Kirk continued:
> >A user of PUA characters is free to define the
> >whole range of PUA characters as consisting of strong R-to-L
> >characters and implementing accordingly. ...
> >
>
> This is not true!
It is true!!
> Users can define only those properties which the
> software that the
D. Starner wrote:
> > "Unicode" has never written any platform software, so it
> > could hardly have made the PUA "too hard to use".
>
> There's two private use planes. That's more than enough area
> to make some of it RTL and some of it combining, and so on for
> the major patterns of pr
Title: RE: What is the principle?
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Kenneth Whistler
> Sent: Tuesday, March 30, 2004 4:30 PM
> The mistake you (and some others on this thread) are making
> is assuming that PUA characters were added to the
At 17:02 -0800 2004-03-30, Mike Ayers wrote:
I feel obligated to take this one step further - these folks are
forgetting that "P" stands for "private". Their use of this space
is their own problem, in all senses. It does not seem reasonable to
me that *any* standard behavior could be expected
Ken,
In the good old days of 8-bit, if one wanted to make a Thaana font
that worked, one used 8-bit Arabic code points for the letters and
Arabic code points for the vowels signs. It was a hack, but it
worked. It worked because the OS (Mac, PC, whatever) treated the
characters appropriately to
At 18:04 -0800 2004-03-30, Kenneth Whistler wrote:
The bidirectional algorithm depends on a partition property. Every
code point that participates in the algorithm has to have *some*
value of that partition for the algorithm to be well-defined for
all encoded characters -- and that includes PUA ch
Michael Everson suggested this might be "preferrable":
> PUA characters can be defined, locally and privately, according to
> some protocal which will WORK if people write software to do what
> they want
Yeah, probably preferrable if you want to use the PUA. To get anything to
work, people have
> At 17:02 -0800 2004-03-30, Mike Ayers wrote:
> > It does not seem reasonable to
> >me that *any* standard behavior could be expected of PUA code
> >points, from operating systems or applications,
and Michael Everson responded:
> Which I assume means: "it's wrong for Unicode to make ANY prop
From: "Kenneth Whistler" <[EMAIL PROTECTED]>
> Consider another example. The normalization algorithm has to work
> for *all* Unicode code points, assigned or not, because it guarantees
> stability into the future when characters are encoded at code points
> which were previously unencoded. It also,
From: "Michael Everson" <[EMAIL PROTECTED]>
> At 17:02 -0800 2004-03-30, Mike Ayers wrote:
> >I feel obligated to take this one step further - these folks are
> >forgetting that "P" stands for "private". Their use of this space
> >is their own problem, in all senses. It does not seem reasonable t
On 30/03/2004 17:32, Michael Everson wrote:
At 17:02 -0800 2004-03-30, Mike Ayers wrote:
I feel obligated to take this one step further - these folks are
forgetting that "P" stands for "private". Their use of this space is
their own problem, in all senses. It does not seem reasonable to me
t
On 30/03/2004 16:46, Kenneth Whistler wrote:
...
Work it out. Any proposal to assign property ranges into the PUA
would run up on the rocks of all the details. And *then* it would
meet a stonewall in the UTC. And *then* it would meet another stonewall
in SC2.
Quit banging your head against the wa
Peter Kirk wrote:
>> Which I assume means: "it's wrong for Unicode to make ANY property
>> pronouncements for ANY PUA characters, since that defines them, and
>> removes the P from the Use."
>
> This is of course a principle which they have already broken, as they
> have defined "default" propert
On 31/03/2004 08:08, Doug Ewell wrote:
...
The perception that no-one has yet implemented custom PUA properties
does not mean that doing so is prohibited or unworkable, any more than
the shortage of widely available rendering engines for the Tibetan and
Khmer encoding models implies that those mo
On: 2004-03-31 06:43:38 -0800 Peter Kirk scribed:
The only alternative I see is to rewrite from scratch the display
routines of my favourite OS. I think banging my head against walls is
likely to be faster. After all, even the hardest wall cracks eventually,
and my head is quite hard.
Bang on, O
On 30/03/2004 16:30, Kenneth Whistler wrote:
...
Uh, sorry, Peter, but the implications here are so much b, err, ...
baloney.
The majority of the world's scripts are left-to-right. They also
happen to be non-Western. There are more *Indic* scripts encoded
in the Unicode Standard than *Western
Title: RE: What is the principle?
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Peter Kirk
> Sent: Wednesday, March 31, 2004 9:12 AM
> On 30/03/2004 16:30, Kenneth Whistler wrote:
> But
> what if users of certain other scripts e.g. RTL scripts want
> [Original Message]
> From: Kenneth Whistler <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
>
> Peter Kirk continued:
>
> > >You can do it privately. See above. But attempting to do such things
> > >in terms of formally specified usages of the PUA is an invitation
> > >to failure of interoperabi
Peter Kirk wrote...
> ... I have a real requirement. The UTC has the power to meet my requirement,
> and to do so rather simply. I am asking them to meet it.
Actually, you are not asking UTC anything. You are discussing the PUA on a
public-access mail list. There's a big difference. This *is* t
On 31/03/2004 10:44, Mike Ayers wrote:
...
>
> Well, I don't quite see why it is business sense for software
> companies
> to support the huge PUAs for variant CJK characters, outside
Support? ROFL! Call up one of those companies and tell them
that you are having trouble displaying PUA
On 31/03/2004 10:44, Mike Ayers wrote:
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Peter Kirk
> Sent: Wednesday, March 31, 2004 9:12 AM
> On 30/03/2004 16:30, Kenneth Whistler wrote:
> But
> what if users of certain other scripts e.g. RTL scripts want just a
> handful of PUA c
On 31/03/2004 12:40, Rick McGowan wrote:
Peter Kirk wrote...
... I have a real requirement. The UTC has the power to meet my requirement,
and to do so rather simply. I am asking them to meet it.
Actually, you are not asking UTC anything. You are discussing the PUA on a
public-access mai
> No. The *only* way to maintain compatibility between your applications
> and the system software is to ensure that your applications only do things
> that are supported by the system software.
If what is meant here by "your applications" is any applications running on your
system, then that
Ernest suggested:
> There are currently some 10 totally unused planes, with not even any
> tentative plans for them, Allocating one or two those into additional
> Private Use Areas with a variety of default characteristics instead of
> the monotonous default characteristics of the existing Privat
From: "Ernest Cline" <[EMAIL PROTECTED]>
> I'd have to take the time to list them, but a quick glance convinces
> me that there are at most several hundred combinations that would
> need to be supported if we limit things to just those combinations
> already in use. (it might take more, if for exa
Peter Kirk wrote...
> I am undecided yet whether to make a formal proposal.
> Ken seems to suggest that this would be a waste of time -
Yes. I also think it would be a waste of time, but...
> although I can see some advantages in obtaining a formal rejection.
... I can also see some value in a
On 31/03/2004 12:28, Ernest Cline wrote:
...
This is the kind of stuff the UTC refuses to start up by trying
to provide some subdivision of semantics in the PUA. *That* is
the principle, by the way, which guides the UTC position on
the PUA: Use at your own risk, by private agreement.
Whic
"Mike Ayers" <[EMAIL PROTECTED]> writes:
> Support? ROFL! Call up one of those companies and tell them that
> you are having trouble displaying PUA fonts, eastern or otherwise. I'd like
> to snoop on that call.
Apple seemed pretty concerned about displaying PUA fonts on Mac OS X
es sense.
Mark
__
http://www.macchiato.com
â à â
- Original Message -
From: "Peter Kirk" <[EMAIL PROTECTED]>
To: "Rick McGowan" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wed, 2004 Mar 31 16:24
Subjec
On 31/03/2004 13:13, Peter Constable wrote:
...
E.g. SIL's Graphite technology can deal with RTL PUA characters, but then it isn't relying on system-supplied services to do complex-script shaping of text.
I am glad to hear this, as it at least offers some hope to those of us
who see the need
> [Original Message]
> From: Peter Kirk <[EMAIL PROTECTED]>
>
> Ernest, I support your general ideas here. But I am concerned about the
> implications of defining PUA characters with combining classes other
> than zero. I can see this causing some confusion with normalisation etc.
> And it do
On 31/03/2004 13:30, Kenneth Whistler wrote:
...
I think you're spitting into the wind if you think you can
force, through the character standardization process, the
major platform vendors to support the kind of PUA functionality
you are after, when they could do so *today* via much more
extensib
On 31/03/2004 14:27, Mark Davis wrote:
While I disagree with most of what you've said on this list, it is not an
unreasonable proposal to change the default properties for some ranges of the
private use blocks. I don't think that this would, in practice, really disturb
any applications, because of
On 31/03/2004 15:32, Ernest Cline wrote:
[Original Message]
From: Peter Kirk <[EMAIL PROTECTED]>
Ernest, I support your general ideas here. But I am concerned about the
implications of defining PUA characters with combining classes other
than zero. I can see this causing some confusion with n
comments below.
Mark
__
http://www.macchiato.com
â à â
- Original Message -
From: "Peter Kirk" <[EMAIL PROTECTED]>
To: "Mark Davis" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wed, 2004
[Original Message]
From: Kenneth Whistler <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Scenario: The UTC listens to you and defines some section of the PUA
as strong right-to-left by default for use in PUA-defined bidirectional
scripts. Somebody else is *already* using that section of the PUA
Philippe Verdy wrote:
This seems highly excessive. We already have plenty of PUA space. All what we
need is a standard way (file format? protocol?) to transport PUA character
properties, and possibly encode a reference (URI?) to the definition file or
service. If Unicode does not want to do this j
On 31/03/2004 17:01, Mark Davis wrote:
...
BTW, you have been mentioning the combining class; you can have combining marks
in the PUA, but they have to have zero combining classes.
Thanks for the clarification. As I have argued elsewhere, zero combining
class should not be a problem. I am mor
On 31/03/2004 17:01, Mark Davis wrote:
...
BTW, you have been mentioning the combining class; you can have combining marks
in the PUA, but they have to have zero combining classes.
Combining marks have neutral bidi properties, and several other
properties, and so inherit these properties from
> Surely Unicode didn't waste two planes for something that
> no one can practically use.
Plane 15 and Plane 16 private use characters weren't the
invention of the UTC, by the way. They derive from the
original specification of ISO/IEC 10646-1. From
ISO/IEC 10646-1: 1993:
"The code positions
This discussion has focused pretty tightly on the *default* properties
of PUA code points, without really addressing the issue of specifying
new properties to override those defaults, and I think that's a mistake.
After all, if you're going to define Private Use characters, it really
isn't enough
From: "Doug Ewell" <[EMAIL PROTECTED]>
To: "Unicode Mailing List" <[EMAIL PROTECTED]>
Cc: "Kenneth Whistler" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 31, 2004 8:38 AM
Subject: PUA properties, default or otherwise (wa
85 matches
Mail list logo
