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
> 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
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 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
Ernest Cline wrote:
The main usage is with compound words such as "ice cream" or
"Louis XIV" or commercial phrases such as "Camry SE" where for
esthetic reasons an author would prefer that the space not expand
upon justification,
Given wide enough measures, good text layout program should be able
t
Asmus Freytag wrote:
and I don't know whether FOUR-PER-EM is the width of a typical space.
FOUR-PER-EM is 1/4 of an em, always. A typical space, however, varies
in width depending on the font.
~fantasai
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 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
From: "Kenneth Whistler" <[EMAIL PROTECTED]>
> > Users can define only those properties which the
> > software that they are using allows them to define. Your argument here
> > completely ignores the distinction between users and software
> > developers.
>
> No it doesn't. I am well aware of the di
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 standard
> with som
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
From: "Kenneth Whistler" <[EMAIL PROTECTED]>
> > Also RFC 1345 indicates that the standard C0 and C1
> > control sets of ISO 6429 (ECMA-48) are used with ISO 8859-1, but I
> > can't be certain if that is just the usual assumption or explicitly given
> > in ISO 8859.
>
> It has nothing to do with IS
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
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.
Unicode 4.0.1 has been released! The data files and documentation are
final and posted on the Unicode site. For details, see the version page for
Unicode 4.0.1 at:
http://www.unicode.org/versions/Unicode4.0.1/
Unicode 4.0.1 is an update version of the Unicode Standard. It adds no new
chara
> > I don't have access to ISO 8859-1 itself, but ECMA-94 (1986), which is
> > supposed to be equivalent, doesn't actually define anything for
> 0x80..0x9F.
> > So I think the term "superset" is in fact justified.
ISO/IEC 8859-1:1998 does not define any characters or mappings
for 0x80..0x9F (or f
Peter Kirk scripsit:
> In each of these cases FIGURE SPACE may be appropriate. Are any of these
> alternative spaces non-breaking? That is also a requirement in my last
> two applications.
You can make anything non-breaking by putting ZWNBSP on both sides of it.
--
John Cowan www.ccil.org/~c
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
On 30/03/2004 11:46, Asmus Freytag wrote:
...
Still, there is a need for a fixed width space with a width equal to the
unjustified width of a normal space .
Perhaps you would like to elaborate where and when that is used. What
problem does a fixed width space solve? Are those circumstances wher
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
> [Original Message]
> From: Asmus Freytag <[EMAIL PROTECTED]>
>
> At 10:12 AM 3/30/2004, Ernest Cline wrote:
>
>
>
> > > [Original Message]
> > > From: Asmus Freytag <[EMAIL PROTECTED]>
> > >
> > > At 12:19 PM 3/29/2004, Ernest Cline wrote:
> > >
> > > >
> > > > UAX #14 makes a rather definitiv
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
"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.)
At 10:12 AM 3/30/2004, Ernest Cline wrote:
> [Original Message]
> From: Asmus Freytag <[EMAIL PROTECTED]>
>
> At 12:19 PM 3/29/2004, Ernest Cline wrote:
>
> >
> >UAX #14 makes a rather definitive statement on this issue, albeit
> >in an obscure place, in Section 3: Introduction.
>
> 4.0.1 will a
From: "Dominikus Scherkl (MGW)" <[EMAIL PROTECTED]>
> > >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 w
> [Original Message]
> From: Asmus Freytag <[EMAIL PROTECTED]>
>
> At 12:19 PM 3/29/2004, Ernest Cline wrote:
>
> >
> >UAX #14 makes a rather definitive statement on this issue, albeit
> >in an obscure place, in Section 3: Introduction.
>
> 4.0.1 will amend that section to correct the wrong impr
From: "John Cowan" <[EMAIL PROTECTED]>
> Mark Davis scripsit:
>
> > Some more details. Usually, by 'extension' one means a superset of
> > the mappings. windows-1252 is formally disjoint from iso-8859-1 --
> > not a superset -- since it has mappings for 0x80..0x9F which are
> > different from iso-
At 04:28 PM 3/29/2004, Kenneth Whistler wrote:
> I will say again as I have said before - but the above (and what I
> snipped) is extra evidence for it - that what is broke ... is
> the rule that the isolated (generally spacing) form of a combining mark
> should be formed by SPACE or NBSP followed
Peter Kirk scripsit:
> I accept that some standards do have sections which are described as
> informative, and as such they are an exception to what I wrote. But as
> the purpose of a standard is to be normative, it is reasonable to
> assume, as I have, that its text is normative unless otherwi
At 07:31 -0500 2004-03-30, John Cowan wrote:
Peter Kirk scripsit:
> Yes it is, in Unicode 4.0.0. Ernest quoted from UAX #14 "All other space
> characters have fixed width." This may be in the standard by mistake,
but it is in the standard. Asmus says that this will be changed in
4.0.1, but tha
On 30/03/2004 04:31, John Cowan wrote:
Peter Kirk scripsit:
Yes it is, in Unicode 4.0.0. Ernest quoted from UAX #14 "All other space
characters have fixed width." This may be in the standard by mistake,
but it is in the standard. Asmus says that this will be changed in
4.0.1, but that has n
- Original Message -
From: "Pavel Adamek" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 30, 2004 10:02 AM
Subject: Re: Printing and Displaying Dependent Vowels
> > # In charts and illustrations in this standard,
> > # the combining nature of these marks
> > # is illust
Peter Kirk scripsit:
> Yes it is, in Unicode 4.0.0. Ernest quoted from UAX #14 "All other space
> characters have fixed width." This may be in the standard by mistake,
> but it is in the standard. Asmus says that this will be changed in
> 4.0.1, but that has not yet been released. If a statemen
> >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
On 29/03/2004 16:28, Kenneth Whistler wrote:
...
Using NBSP rather than SPACE has several advantages, and has long been
specified in Unicode, although not widely implemented. It is less likely
to occur accidentally. But it has disadvantages, especially that it will
always be a spacing characte
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
On Monday, March 29, 2004 8:11 PM
John Cowan va escriure:
> Well, it depends on what the equivoque "combining marks" in the title
> of Section 7.7 means.
Ah! This is the place where I did not seek into! (It was not obvious to me
that text about the dependent vowel marks has to be searched into th
> 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
> # In charts and illustrations in this standard,
> # the combining nature of these marks
> # is illustrated by applying them to a dotted circle,
How should be such chart coded?
The character 25CC DOTTED CIRCLE was mentioned
as a possible base character,
but the on-line reference says:
"note that
39 matches
Mail list logo
