Michael, what you are also probably not realizing is that the request is not
for *all* numbers, but for decimal numbers (general_category=decimal_number)
http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:general_category:decimal_number
:]
>From just a quick scan, it appears that they are cu
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*. So my hyperbole was not outrageous. And nobody has
actuall
> Bill,
> Michael is no programmer, hence he doesn't have first hand understanding why
> programmers distiguish between character set mapping (normally requiring
> look-up tables) and digit conversion (normally done by offset calculations).
>
> That said, there are enough programmers on the committ
-- Forwarded message --
From: Bill Poser
Date: Sat, Jul 24, 2010 at 6:02 PM
Subject: Re: ? Reasonable to propose stability policy on numeric type = decimal
To: Michael Everson
On Sat, Jul 24, 2010 at 4:25 PM, Michael Everson wrote:
> On 24 Jul 2010, at 23:00, Bill Poser wrote:
On 25 Jul 2010, at 01:34, karl williamson wrote:
> the proposal did not ask for ones at one or eights at eight. It asked for
> contiguity. Why is this ad odds with common sense and practical
> code-position assignment?
It is unnecessary to make a rule about it.
Michael Everson * http://www.e
Michael Everson wrote:
On 24 Jul 2010, at 23:00, Bill Poser wrote:
On Sat, Jul 24, 2010 at 1:00 PM, Michael Everson wrote:
Digits can be scattered randomly about the code space and it wouldn't make any
difference.
Having written a library for performing conversions between Unicode strings
On 24 Jul 2010, at 23:00, Bill Poser wrote:
> On Sat, Jul 24, 2010 at 1:00 PM, Michael Everson wrote:
>
>> Digits can be scattered randomly about the code space and it wouldn't make
>> any difference.
>
> Having written a library for performing conversions between Unicode strings
> and number
On 7/24/2010 3:00 PM, Bill Poser wrote:
On Sat, Jul 24, 2010 at 1:00 PM, Michael Everson wrote:
Digits can be scattered randomly about the code space and it wouldn't make any
difference.
Having written a library for performing conversions between Unicode
strings and numbers, I disag
On Sat, Jul 24, 2010 at 1:00 PM, Michael Everson wrote:
> Digits can be scattered randomly about the code space and it wouldn't make
> any difference.
Having written a library for performing conversions between Unicode
strings and numbers, I disagree. While it is not all that hard to deal
with
On 24 Jul 2010, at 20:34, karl williamson wrote:
> What would the problems be of having a stability policy in regards to
> assigning characters to have numeric type = decimal, something like the
> following:
>
> "New scripts or forms (like mathematical mono space) that have decimal
> numbers
What would the problems be of having a stability policy in regards to
assigning characters to have numeric type = decimal, something like the
following:
"New scripts or forms (like mathematical mono space) that have decimal
numbers will be assigned so that those decimal numbers occupy at least
"Kent Karlsson" wrote:
> Den 2010-07-24 10.07, skrev "Philippe Verdy" :
>
> > Double diacritics have a combining property equal to zero, so they
>
> No, they don't. The above ones have combining class 234 and the below
> ones have combining class 233 (other characters with the word DOUBLE
> in the
"Clark S. Cox III"
> How can *any* combining character have a combining class of zero? Isn't that
> a contradiction in terms?
>
> The U+035D in your example, for instance, has a combining class of 234.
No contradiction. Not all combining characters have a non-zero
combining class. The combining
> De : vanis...@boil.afraid.org
> Guys, does nobody read the bloody Standard anymore!?
>
> You CAN currently add a diacritic on top of a double diacritic. The "other"
> base character is called the Combining Grapheme Joiner (U+304F).
Sorry, I had forgotten this one. Note that I was not sure abou
Den 2010-07-24 10.07, skrev "Philippe Verdy" :
> Double diacritics have a combining property equal to zero, so they
No, they don't. The above ones have combining class 234 and the below
ones have combining class 233 (other characters with the word DOUBLE
in them are 'double' in some other way):
Guys, does nobody read the bloody Standard anymore!?
You CAN currently add a diacritic on top of a double diacritic. The "other"
base character is called the Combining Grapheme Joiner (U+304F).
>From V. 5.0, ch 7.9:
Occasionally one runs across orthographic conventions that use a dot, an acute
"Philippe Verdy" wrote:
> But even with this case, you wont be able to encode with the ZWJ trick
> in plain text, such groupings that are expressed this way in TeX:
>
> \breve{ \breve{oo} x \breve{ o\acute{o} } }
>
> Because double diacritics encoded in Unicode can't be safely stacked
> together
> Message du 24/07/10 09:02
> De : "William_J_G Overington"
> A : unicode@unicode.org
> Copie à : wjgo_10...@btinternet.com
> Objet : Using Combining Double Breve and expressing characters perhaps as if
> struck out.
>
>
> I have been looking at the following thread, which is entitled "Making Fon
I note this entry just added in last March:
Narb 106 Old North Arabian (Ancient North Arabian) nor-arabien
The French column is clearly containing a typo for the word "nord" in the
compound (see also: nord-coréen, nord-
américain). (And the adjective "arabien" was completely invented from an
in
19 matches
Mail list logo
