Re: Reasonable to propose stability policy on numeric type = decimal

> From: karl williamson (pub...@khwilliamson.com) > Date: Sun Jul 25 2010 - 17:00:14 CDT > . . . >> From: cewcat...@hotmail.com >> Date: Sun, 25 Jul 2010 16:24:01 -0400 >> >> >> > . . . >> > Date: Sun, 25 Jul 2010 10:43:11 -0600 >> > From: pub...@khwilliamson.com >> > > . . . >> > >>

Re: Reasonable to propose stability policy on numeric type = decimal

On 7/25/2010 6:05 PM, Martin J. Dürst wrote: On 2010/07/26 4:37, Asmus Freytag wrote: PPS: a very hypothetical tough case would be a script where letters serve both as letters and as decimal place-value digits, and with modern living practice. Well, there actually is such a script, namely H

Re: Reasonable to propose stability policy on numeric type = decimal

On 2010/07/26 4:37, Asmus Freytag wrote: PPS: a very hypothetical tough case would be a script where letters serve both as letters and as decimal place-value digits, and with modern living practice. Well, there actually is such a script, namely Han. The digits (一、二、 三、四、五、六、七、八、九、〇) are use

Re: CSUR Tonal

I don't know if this belongs on the public Unicode list or not. I assume anyone who feels it should not will not keep their feelings secret for long. Luke-Jr wrote: I would appreciate any constructive input on this future proposal (for CSUR, not Unicode). Doug, do you mind if Tonal is positi

Re: Reasonable to propose stability policy on numeric type = decimal

CE Whitehead wrote: Sorry for my last email; I have that signature in hotmail and always delete it but do have it for a few private emails; but sorry as I ment to delete it but was very very tired. --C. E. Whitehead cewcat...@hotmail.com -

RE: Reasonable to propose stability policy on numeric type = decimal

Sorry for my last email; I have that signature in hotmail and always delete it but do have it for a few private emails; but sorry as I ment to delete it but was very very tired. --C. E. Whitehead cewcat...@hotmail.com From: cewcat...@hotmail.com To: pub...@khwilliamson.com; verd...@wan

RE: Reasonable to propose stability policy on numeric type = decimal

Damn this indecision; I don't know; shall I take an axe to it, or shall I let it grow. --from Judith Wright, "That Seed" > Date: Sun, 25 Jul 2010 10:43:11 -0600 > From: pub...@khwilliamson.com > To: verd...@wanadoo.fr > CC: kent.karlsso...@telia.com; unicode@unicode.org > Subject: Re: Reas

Re: Reasonable to propose stability policy on numeric type = decimal

The short answer to Karl's question is that there will not be an absolute guarantee. The long answer is that, partly for the reasons he's mentioned, this won't be a practical problem. A. Most of the living scripts that are in wide use have been encoded, including whatever digits are in use.

Re: CSUR Tonal

I would appreciate any constructive input on this future proposal (for CSUR, not Unicode). Doug, do you mind if Tonal is positioned after your Ewellic script (maybe you plan to extend it?) from U+E6D0 to U+E6FF? Specific questions I have: - Am I using COMBINING correctly? Is it sufficient for fo

Re: Reasonable to propose stability policy on numeric type = decimal

Philippe Verdy wrote: "Kent Karlsson" wrote: Den 2010-07-25 03.09, skrev "Michael Everson" : On 25 Jul 2010, at 02:02, Bill Poser wrote: As I said, it isn't a huge issue, but scattering the digits makes the programming a bit more complex and error-prone and the programs a little less efficien

Re: Reasonable to propose stability policy on numeric type = decimal

"Kent Karlsson" wrote: > Den 2010-07-25 03.09, skrev "Michael Everson" : > > On 25 Jul 2010, at 02:02, Bill Poser wrote: > >> As I said, it isn't a huge issue, but scattering the digits makes the > >> programming a bit more complex and error-prone and the programs a little > >> less > >> efficien

Re: ? Reasonable to propose stability policy on numeric type = decimal

Den 2010-07-25 03.09, skrev "Michael Everson" : > On 25 Jul 2010, at 02:02, Bill Poser wrote: > >> As I said, it isn't a huge issue, but scattering the digits makes the >> programming a bit more complex and error-prone and the programs a little less >> efficient. > > But it would still *work*.