org
Subject : Re: Private Use areas
Hi
Thank you for your posts from earlier today.
Actually I learned about JSON yesterday and I am thinking that using JSON could
well be a good idea.
I found a helpful page with diagrams.
http://www.json.org/
Although I hope that a format of record
Hi
Thank you for your posts from earlier today.
Actually I learned about JSON yesterday and I am thinking that using JSON could
well be a good idea.
I found a helpful page with diagrams.
http://www.json.org/
Although I hope that a format of recording information about the properties of
On 08/28/2018 04:26 AM, William_J_G Overington via Unicode wrote:
Hi
Mark E. Shoulson wrote:
I'm not sure what the advantage is of using circled characters instead of plain
old ascii.
My thinking is that "plain old ascii" might be used in the text encoded in the file. Sometimes a file
On 08/28/2018 11:58 AM, William_J_G Overington via Unicode wrote:
Asmus Freytag wrote:
There are situations where an ad-hoc markup language seems to fulfill a need that is not
well served by the existing full-fledged markup languages. You find them in internet
"bulletin boards" or services
On 31/08/18 07:27 Janusz S. Bień via Unicode wrote:
[…]
> > Given NamesList.txt / Code Charts comments are kept minimal by design,
> > one couldn’t simply pop them into XML or whatever, as the result would be
> > disappointing and call for completion in the aftermath. Yet another task
> >
The XML files in these folders:
https://unicode.org/repos/cldr/tags/latest/common/
But I agree. I spent an extreme amount of time to get somewhat used to
cldr.unicode.org and and the data repo, and still I have no clue,
where to find a concrete piece of information without digging into the
site.
On Thu, Aug 30 2018 at 2:27 +0200, unicode@unicode.org writes:
[...]
> Given NamesList.txt / Code Charts comments are kept minimal by design,
> one couldn’t simply pop them into XML or whatever, as the result would be
> disappointing and call for completion in the aftermath. Yet another task
>
> On 29 August 2018 at 06:47 "Janusz S. Bień via Unicode"
> wrote:
>
> > >
> > Storing this information in a font, by hook or crook, would lock
> > users
> > of those PUA characters into that font. At that rate, you might as
> > well
> > use
On 29/08/18 07:55, Janusz S. Bień via Unicode wrote:
>
> On Tue, Aug 28 2018 at 9:43 -0700, unicode@unicode.org writes:
> > On August 23, 2011, Asmus Freytag wrote:
> >
> >> On 8/23/2011 7:22 AM, Doug Ewell wrote:
> >>> Of all applications, a word processor or DTP application would want
> >>> to
>
> On 29 August 2018 at 13:05 Andrew West via Unicode
> wrote:
>
> I tested with Word 2007, and normal PUA characters from my font were
>
> displayed with vertical orientation in a vertical text box, but Plane
> 15 PUA characters were rotated.
>
And then the original
On Wed, 29 Aug 2018 at 11:18, wrote:
>
> I was using a change horizontal to vertical text feature in office, the
> PUA characters being from plane 15.
I tested with Word 2007, and normal PUA characters from my font were
displayed with vertical orientation in a vertical text box, but Plane
15 PUA
Dear Andrew,
I was using a change horizontal to vertical text feature in office, the
PUA characters being from plane 15.
Regards
John
On 2018-08-29 16:32, Andrew West via Unicode wrote:
On Wed, 29 Aug 2018 at 05:07, via Unicode wrote:
Yes, as Richard says when CJK Zhuang text is
On Wed, 29 Aug 2018 at 05:07, via Unicode wrote:
>
> Yes, as Richard says when CJK Zhuang text is displayed vertically whilst
> the Zhuang characters in Unicode remain upright, but those with PUA
> codepoints are rotated 90°.
John, you did not explain by what mechanism you were trying to display
On Tue, 28 Aug 2018 at 18:15, WORDINGHAM RICHARD via Unicode
wrote:
>
> Unicode is doing what it can in this matter:
>
> (a) Zhuang PUA characters are being made individually obsolete.
Not by a nebulous entity called "Unicode", or even by the Unicode
Consortium per se, but by the hard work over
John Knightley wrote,
> Yes, as Richard says when CJK Zhuang text is displayed
> vertically whilst the Zhuang characters in Unicode remain
> upright, but those with PUA codepoints are rotated 90°.
> This is because the PUA characters are treated like English
> text, which are correctly rotated
On Tue, Aug 28 2018 at 9:43 -0700, unicode@unicode.org writes:
> On August 23, 2011, Asmus Freytag wrote:
>
>> On 8/23/2011 7:22 AM, Doug Ewell wrote:
>>> Of all applications, a word processor or DTP application would want
>>> to know more about the properties of characters than just whether
>>>
Dear Richard and Peter,
apologies for the lack of clarity. Let me try to explain below.
On 2018-08-29 01:13, WORDINGHAM RICHARD via Unicode wrote:
On 27 August 2018 at 15:22 Peter Constable via Unicode
wrote:
Layout engines that support CJK vertical layout do not rely on the
'vert' feature
>
> On 27 August 2018 at 15:22 Peter Constable via Unicode
> wrote:
>
> Layout engines that support CJK vertical layout do not rely on the 'vert'
> feature to rotate glyphs for CJK ideographs, but rather rotate the glyph 90°
> and switch to using vertical glyph metrics. The 'vert'
On August 23, 2011, Asmus Freytag wrote:
> On 8/23/2011 7:22 AM, Doug Ewell wrote:
>> Of all applications, a word processor or DTP application would want
>> to know more about the properties of characters than just whether
>> they are RTL. Line breaking, word breaking, and case mapping come to
>>
Asmus Freytag wrote:
> There are situations where an ad-hoc markup language seems to fulfill a need
> that is not well served by the existing full-fledged markup languages. You
> find them in internet "bulletin boards" or services like GitHub, where pure
> plain text is too restrictive but the
try
code number for the various emoji that they want? If there is a threshold of
proving usage and so on, or of showing that the designs have been produced AT a
business or AT a college or whatever, then the system will only work for some
users of the Private Use Areas.
My opinion is that the system
Hi
Mark E. Shoulson wrote:
> I'm not sure what the advantage is of using circled characters instead of
> plain old ascii.
My thinking is that "plain old ascii" might be used in the text encoded in the
file. Sometimes a file containing Private Use Area characters is a mix of
regular
On 8/27/2018 2:20 PM, Rebecca
Bettencourt via Unicode wrote:
> That
sounds like a non-conformant use of characters
But there's nothing wrong with proposing a higher-level protocol;
indeed, that's what Ken Whistler was saying: you need a protocol to
transmit this information. It's metadata, so it will perforce be a
higher-level protocol of some kind, whether transmitting actually
out-of-band or reserving
On 08/27/2018 05:18 PM, James Kass via Unicode wrote:
William Overington wrote,
On Mon, Aug 27, 2018 at 12:59 AM, William_J_G Overington
wrote:
Use circled digits U+24EA, U+2460 .. U+2469, and Circled Latin letters
U+24B6 .. U+24E9.
Use U+2473 as if it were a circled space.
James Kass wrote:
> If a user has thousands of files using PUA characters, and all the files are
> using the same PUA convention, why would each file need to contain metadata
> for each PUA character used within? (Rhetorical)
Because each such file would then be self-contained and
>
> > That sounds like a non-conformant use of characters in the U+24xx block.
>
> Well, you are an expert on these things and I do not understand as to with
> what it would be non-conformant.
>
>
A conformant process must interpret ⓅⓊⒶⒹⒶⓉⒶ as the characters ⓅⓊⒶⒹⒶⓉⒶ and
not as a signal to process
William Overington wrote,
On Mon, Aug 27, 2018 at 12:59 AM, William_J_G Overington
wrote:
> Use circled digits U+24EA, U+2460 .. U+2469, and Circled Latin letters
> U+24B6 .. U+24E9.
>
> Use U+2473 as if it were a circled space.
ⓌⒽⓎ◯ⓃⓄⓉ◯ⓊⓈⒺ◯ⓉⒽⒺ◯ⒸⒾⓇⒸⓁⒺⒹ◯ⓈⓅⒶⒸⒺ◯
ⒻⓄⓇ◯ⓉⒽⒺ◯ⒸⒾⓇⒸⓁⒺⒹ◯ⓈⓅⒶⒸⒺ？
ter...@microsoft.com,
wjgo_10...@btinternet.com, m...@kli.org, kenwhist...@att.net,
richard.wording...@ntlworld.com, jameskass...@gmail.com
Subject : Re: Private Use areas
Well, it is a pity that you did not send your reply to the Unicode mailing list.
> That sounds like a non-conformant use of char
Peter Constable wrote,
> That sounds like a non-conformant use of characters in the U+24xx block.
Non-conformant? Well, it's probably overkill anyway. A simpler
method of identifying which PUA convention is being used for a file
would be to either have the first line of the file being
This was meant to go to the list.
From: Peter Constable
Sent: Monday, August 27, 2018 12:33 PM
To: wjgo_10...@btinternet.com; jameskass...@gmail.com;
richard.wording...@ntlworld.com; m...@kli.org; beckie...@gmail.com;
verd...@wanadoo.fr
Subject: RE: Private Use areas
That sounds like a non
.
William Overington
Monday 27 August 2018
Original message
>From : unicode@unicode.org
Date : 2018/08/21 - 23:23 (GMTDT)
To : d...@ewellic.org
Cc : unicode@unicode.org
Subject : Re: Private Use areas
On Tue, Aug 21, 2018 at 3:02 PM Doug Ewell via Unicode
wrote:
Ken Whistler wr
: Private Use areas (was: Re: Thoughts on working with the Emoji
Subcommittee (was ...))
On Tue, 21 Aug 2018 08:53:18 +0800
via Unicode wrote:
> On 2018-08-21 08:04, Mark E. Shoulson via Unicode wrote:
> > Still, maybe it
> > doesn't really matter much: your special-purpose fon
> On 21 August 2018 at 01:04 "Mark E. Shoulson via Unicode"
> wrote:
>
> It is kind of a bummer, though, that you can't experiment (easily? or at
> all?) in the PUA with scripts that have complex behavior, or even
> not-so-complex behavior like accents & combining marks, or RTL
On Thu, Aug 23 2018 at 22:15 +0100, unicode@unicode.org writes:
> On Thu, 23 Aug 2018 21:47:03 +0200
> "Janusz S. Bień via Unicode" wrote:
>
>> My needs are very simple, for example C-x 8 Return LATIN CAPITAL
>> LETTER A WITH MACRON AND BREVE [MUFI] should yield the character with
>> the code
On Fri, Aug 24 2018 at 16:12 +0300, e...@gnu.org writes:
>> From: jsb...@mimuw.edu.pl (Janusz S. Bień)
>> Cc: unicode@unicode.org, richard.wording...@ntlworld.com
>> Date: Thu, 23 Aug 2018 21:47:03 +0200
>>
>> I'm very glad you join the discussion.
>
> I'm sorry for not joining sooner. In my
:23 (GMTDT)
To : unicode@unicode.org
Subject : Re: Private Use areas
On Tue, Aug 21, 2018 at 10:21 AM, Janusz S. Bień via Unicode
wrote:
I think PUA users should provide the
properties of the characters used in a form analogical to the Unicode
itself, and the software should be able to
> Date: Thu, 23 Aug 2018 22:15:10 +0100
> From: Richard Wordingham via Unicode
>
> On Thu, 23 Aug 2018 21:47:03 +0200
> "Janusz S. Bień via Unicode" wrote:
>
> > My needs are very simple, for example C-x 8 Return LATIN CAPITAL
> > LETTER A WITH MACRON AND BREVE [MUFI] should yield the
> From: jsb...@mimuw.edu.pl (Janusz S. Bień)
> Cc: unicode@unicode.org, richard.wording...@ntlworld.com
> Date: Thu, 23 Aug 2018 21:47:03 +0200
>
> I'm very glad you join the discussion.
I'm sorry for not joining sooner. In my defense, I missed the
reference to Emacs, and the rest of the
On Thu, Aug 23 2018 at 11:49 -0700, beckie...@gmail.com writes:
> On Thu, Aug 23, 2018 at 5:10 AM, Janusz S. Bień wrote:
>
> > I already provide this myself for my uses of the PUA as well as the
> > CSUR and any vendor-specific agreements I can find:
> >
> >
On Thu, 23 Aug 2018 21:47:03 +0200
"Janusz S. Bień via Unicode" wrote:
> My needs are very simple, for example C-x 8 Return LATIN CAPITAL
> LETTER A WITH MACRON AND BREVE [MUFI] should yield the character with
> the code E010. I can provide the list of names and codes.
While it should obviously
On Thu, 23 Aug 2018 20:34:20 +0200
"Janusz S. Bień via Unicode" wrote:
> This is a typical but IMHO obsolete perspective. Fonts are for
> *rendering*, new characters and variants are more and more often
> needed for *input* of real life old texts with sufficient precision.
If we're talking
On Thu, Aug 23 2018 at 22:17 +0300, e...@gnu.org writes:
>> Date: Thu, 23 Aug 2018 20:30:52 +0200
>> Cc: Richard Wordingham
>> From: "Janusz S. Bień via Unicode"
>>
>> >> and in Emacs - to my disappointed it looks like the Unicode data are
>> >> set at the compile time, but perhaps this can be
On Thu, Aug 23, 2018 at 5:10 AM, Janusz S. Bień wrote:
> > I already provide this myself for my uses of the PUA as well as the
> > CSUR and any vendor-specific agreements I can find:
> >
> > http://www.kreativekorp.com/charset/PUADATA/
>
> I would prefer to see the data in a repository, so
On Thu, Aug 23 2018 at 17:26 +0100, unicode@unicode.org writes:
> On Thu, 23 Aug 2018 17:39:15 +0200
> Philippe Verdy via Unicode wrote:
>
>> You make a confusion: I do not propose "hacking" existing codes, but
>> instead adding new codes for private variations. It's then up to PUV
>> sequence
On Thu, Aug 23 2018 at 17:11 +0100, unicode@unicode.org writes:
> On Thu, 23 Aug 2018 14:10:35 +0200
> "Janusz S. Bień via Unicode" wrote:
>
>> What kind of software do you have in mind?
>>
>> I'm primarily interested in the locally developed programs
>>
>>
Le jeu. 23 août 2018 à 18:31, Richard Wordingham via Unicode <
unicode@unicode.org> a écrit :
> On Thu, 23 Aug 2018 17:39:15 +0200
> Philippe Verdy via Unicode wrote:
>
> > You make a confusion: I do not propose "hacking" existing codes, but
> > instead adding new codes for private variations.
On Thu, 23 Aug 2018 17:39:15 +0200
Philippe Verdy via Unicode wrote:
> You make a confusion: I do not propose "hacking" existing codes, but
> instead adding new codes for private variations. It's then up to PUV
> sequence authors to choose an appropropriate base character that can
> have the
On Thu, 23 Aug 2018 14:10:35 +0200
"Janusz S. Bień via Unicode" wrote:
> What kind of software do you have in mind?
>
> I'm primarily interested in the locally developed programs
>
> https://bitbucket.org/jsbien/unihistext/
>
> https://bitbucket.org/jsbien/fntsample-fork-with-ucd-comments/
You make a confusion: I do not propose "hacking" existing codes, but
instead adding new codes for private variations. It's then up to PUV
sequence authors to choose an appropropriate base character that can have
the properties they want to be inherited by the private-use variation
sequence, or to
On Tue, Aug 21 2018 at 11:23 -0700, unicode@unicode.org writes:
> On Tue, Aug 21, 2018 at 10:21 AM, Janusz S. Bień via Unicode
> wrote:
>
> I think PUA users should provide the
> properties of the characters used in a form analogical to the Unicode
> itself, and the software should be able to
On Wed, 22 Aug 2018 11:58:58 +0200
Philippe Verdy via Unicode wrote:
> For now there's still no way to have variant sequences unless they are
> registered and standardized by Unicode but registration should be not
> needed (forbidden) for sequences containing PUV.
I believe this scheme is no
May be this debate could find an end if there was a way to encode "private
use variants", so that we can override an existing character with correct
properties by creating a custom variant, which would immediately inherit
the properties of the base character on which it is encoded.
But for now
On Wednesday, 22 August 2018, Mark E. Shoulson via Unicode <
unicode@unicode.org> wrote:
> On 08/21/2018 02:03 PM, Ken Whistler via Unicode wrote:
>
>>
>>
> Best we can do is shout loudly at OpenType tables and hope to cram in
> behavior (or at least appearance, which is more likely all we can
On 08/21/2018 02:03 PM, Ken Whistler via Unicode wrote:
On 8/21/2018 7:56 AM, Adam Borowski via Unicode wrote:
On Mon, Aug 20, 2018 at 05:17:21PM -0700, Ken Whistler via Unicode wrote:
On 8/20/2018 5:04 PM, Mark E. Shoulson via Unicode wrote:
Is there a block of RTL PUA also?
No.
Perhaps
On Tue, Aug 21, 2018 at 3:02 PM Doug Ewell via Unicode
wrote:
> Ken Whistler wrote:
>
> > The way forward for folks who want to do this kind thing is:
> >
> > 1. Define a *protocol* for reliable interchange of custom character
> > property information about PUA code points.
>
> I've often
Ken Whistler wrote:
> The way forward for folks who want to do this kind thing is:
>
> 1. Define a *protocol* for reliable interchange of custom character
> property information about PUA code points.
I've often thought that would be a great idea. You can't get to steps 2
and 3 without step 1.
On Tue, Aug 21, 2018 at 11:03:41AM -0700, Ken Whistler via Unicode wrote:
>
> On 8/21/2018 7:56 AM, Adam Borowski via Unicode wrote:
> > On Mon, Aug 20, 2018 at 05:17:21PM -0700, Ken Whistler via Unicode wrote:
> > > On 8/20/2018 5:04 PM, Mark E. Shoulson via Unicode wrote:
> > > > Is there a
On Tue, 21 Aug 2018 11:03:41 -0700
Ken Whistler via Unicode wrote:
> On 8/21/2018 7:56 AM, Adam Borowski via Unicode wrote:
> Really? Suppose someone wants to implement a bicameral script in PUA.
> They would need case mappings for that, and how would those be
> "better represented in the font
On Tue, Aug 21, 2018 at 10:21 AM, Janusz S. Bień via Unicode <
unicode@unicode.org> wrote:
> I think PUA users should provide the
> properties of the characters used in a form analogical to the Unicode
> itself, and the software should be able to use this additional
> information.
>
I already
On 8/21/2018 7:56 AM, Adam Borowski via Unicode wrote:
On Mon, Aug 20, 2018 at 05:17:21PM -0700, Ken Whistler via Unicode wrote:
On 8/20/2018 5:04 PM, Mark E. Shoulson via Unicode wrote:
Is there a block of RTL PUA also?
No.
Perhaps there should be?
This is a periodic suggestion that
2011 Thread:
https://www.unicode.org/mail-arch/unicode-ml/y2011-m08/0124.html
Please read in particular these two:
- https://www.unicode.org/mail-arch/unicode-ml/y2011-m08/0174.html
- https://www.unicode.org/mail-arch/unicode-ml/y2011-m08/0212.html
(tl;dr: 1. the PUA set is fixed, 2. being
On Tue, Aug 21 2018 at 16:56 +0200, unicode@unicode.org writes:
> On Mon, Aug 20, 2018 at 05:17:21PM -0700, Ken Whistler via Unicode wrote:
>> On 8/20/2018 5:04 PM, Mark E. Shoulson via Unicode wrote:
>> > Is there a block of RTL PUA also?
>>
>> No.
>
> Perhaps there should be?
>
> What about
On Mon, Aug 20, 2018 at 05:17:21PM -0700, Ken Whistler via Unicode wrote:
> On 8/20/2018 5:04 PM, Mark E. Shoulson via Unicode wrote:
> > Is there a block of RTL PUA also?
>
> No.
Perhaps there should be?
What about designating a part of the PUA to have a specific property? Only
certain
On Tue, 21 Aug 2018 08:53:18 +0800
via Unicode wrote:
> On 2018-08-21 08:04, Mark E. Shoulson via Unicode wrote:
> > Still, maybe it
> > doesn't really matter much: your special-purpose font can treat any
> > codepoint any way it likes, right?
> Not all properties come from the font. For
Doug Ewell wrote:
> Yes, you run the risk of someone else's PUA implementation colliding with
> yours. That's why you create a Private Use Agreement, and make sure it's
> prominently available to people who want to use your solution. It's not like
> there are hundreds of PUA schemes anyway.
On 2018-08-21 08:04, Mark E. Shoulson via Unicode wrote:
On 08/20/2018 03:12 PM, Mark Davis ☕️ via Unicode wrote:
... some people who would call a PUA solution either batty > or
crazy.
I don't think it is either batty or crazy. People can certainly use
the PUA to interchange text (assuming
On 8/20/2018 5:04 PM, Mark E. Shoulson via Unicode wrote:
Is there a block of RTL PUA also?
No.
--Ken
On 08/20/2018 03:12 PM, Mark Davis ☕️ via Unicode wrote:
> ... some people who would call a PUA solution either batty
> or crazy.
I don't think it is either batty or crazy. People can certainly use
the PUA to interchange text (assuming that they have downloaded fonts
and keyboards or some
Mark Davis wrote:
> The only caution I would give is that people shouldn't expect general
> purpose software to do anything with PUA text that depends on
> character properties.
Very true, and a good point. People with creative PUA ideas do sometimes
expect this to magically work.
I have
> ... some people who would call a PUA solution either batty
> or crazy.
I don't think it is either batty or crazy. People can certainly use the PUA
to interchange text (assuming that they have downloaded fonts and keyboards
or some other input method beforehand), and
it
can definitely serve as
71 matches
Mail list logo
