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

2010-07-26 Thread karl williamson
Mark Davis ☕ wrote: > the analogy to the existing such policies seems strained at best. > In practice this is what we do. I just don't think we need more rules. There are many such policies: see http://www.unicode.org/policies/stability_policy.html#Property_Value (or the more accessible htt

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

2010-07-26 Thread karl williamson
Asmus Freytag wrote: 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 s

Re: VS characters, default ignorable property and text search and collation

2010-07-26 Thread Shriramana Sharma
Thanks Kenneth Whistler and Mark Davis. That clarifies the situation. -- Shriramana Sharma

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

2010-07-26 Thread Asmus Freytag
On 7/26/2010 12:13 PM, Mark Davis ☕ wrote: I agree that having it stated at point of use is useful - and we do that in other cases covered by stability clauses; but we can only state it IF we have the corresponding stability policy. Mark, The statement in your "but" clause really isn't correct

Re: VS characters, default ignorable property and text search and collation

2010-07-26 Thread Mark Davis ☕
Mark *— Il meglio è l’inimico del bene —* On Mon, Jul 26, 2010 at 09:40, Shriramana Sharma wrote: > Hello list. > > I have a question about VS characters and the default ignorable property. > > TUS 5.2 ch 16.4 clearly states that VS characters are default ignorable. Ch > 5.21 states that defau

Re: VS characters, default ignorable property and text search and collation

2010-07-26 Thread Kenneth Whistler
Sharma asked: > I have a question about VS characters and the default ignorable property. > > TUS 5.2 ch 16.4 clearly states that VS characters are default ignorable. > Ch 5.21 states that default ignorable characters are to be ignored in > rendering (except in specialized modes which show hidd

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

2010-07-26 Thread Mark Davis ☕
I agree that having it stated at point of use is useful - and we do that in other cases covered by stability clauses; but we can only state it IF we have the corresponding stability policy. Mark *— Il meglio è l’inimico del bene —* On Mon, Jul 26, 2010 at 11:06, Asmus Freytag wrote: > On 7/26

VS characters, default ignorable property and text search and collation

2010-07-26 Thread Shriramana Sharma
Hello list. I have a question about VS characters and the default ignorable property. TUS 5.2 ch 16.4 clearly states that VS characters are default ignorable. Ch 5.21 states that default ignorable characters are to be ignored in rendering (except in specialized modes which show hidden characte

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

2010-07-26 Thread Asmus Freytag
On 7/26/2010 6:55 AM, John Burger wrote: Mark Davis ☕ wrote: From just a quick scan, it appears that they are currently all contiguous within their respective groups. If we were to impose a stability policy, it would be a constraint on the general_category: we would not assign general_categor

Re: CSUR Tonal

2010-07-26 Thread Luke-Jr
On Monday, July 26, 2010 09:55:30 am Doug Ewell wrote: > A superscript letter, representing the multiplier or divisor, before or > after the base unit would be plain text. In my experimenting with fonts, I also noticed that the Unicode superscripts mentioned by Kent have a lower floor from that w

Re: CSUR Tonal

2010-07-26 Thread Luke-Jr
On Sunday, July 25, 2010 07:48:58 pm Doug Ewell wrote: > There is a contiguous block of over 4,200 code points starting at U+E830 > (after Monofon) and it seems to me that could be used for Tonal instead. I have since sending my original message moved my draft proposal to U+E9D0, as many of the b

RE: CSUR Tonal

2010-07-26 Thread Doug Ewell
"Luke-Jr" wrote: >> A superscript letter, representing the multiplier or divisor, before or >> after the base unit would be plain text. > > In my experimenting with fonts, I also noticed that the Unicode superscripts > mentioned by Kent have a lower floor from that which is defined by Tonal, at

Re: Using Combining Double Breve and expressing characters perhaps as if struck out.

2010-07-26 Thread Markus Scherer
There are 857 combining marks with combining class of 0: http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[:M:]%26[:ccc%3D0:]]&abb=on&g= On Sat, Jul 24, 2010 at 11:25 AM, Philippe Verdy wrote: > "Kent Karlsson" wrote: > > Den 2010-07-24 10.07, skrev "Philippe Verdy" : > > > > > Double dia

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

2010-07-26 Thread John H. Jenkins
On Jul 24, 2010, at 7:09 PM, Michael Everson wrote: > 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 *w

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

2010-07-26 Thread Mark Davis ☕
> the analogy to the existing such policies seems strained at best. > In practice this is what we do. I just don't think we need more rules. There are many such policies: see http://www.unicode.org/policies/stability_policy.html#Property_Value (or the more accessible http://www.unicode.org/policie

Re: CSUR Tonal

2010-07-26 Thread Doug Ewell
"Luke-Jr" wrote: These are not really combining marks; they appear to be nothing more than ordinary Latin superscript letters. As such, I would suggest not only that the "multiplication" and "division" superscripts be unified with each other, but that they be unified with already-encoded La

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

2010-07-26 Thread John Burger
Mark Davis ☕ wrote: From just a quick scan, it appears that they are currently all contiguous within their respective groups. If we were to impose a stability policy, it would be a constraint on the general_category: we would not assign general_category=decimal_number to any character unl

Re: ISO 15924 update

2010-07-26 Thread Michael Everson
On 26 Jul 2010, at 10:22, Petr Tomasek wrote: > Does it mean the "Old North Arabic" will come to unicode soon? Awww, and we meant it to be a surprise... ;-) In this case, yes, it does, though ISO 15924 is not really an indicator of such things. > Thanks! Prosim! Michael Everson * http://www.

Re: ISO 15924 update

2010-07-26 Thread Petr Tomasek
On Fri, Jul 23, 2010 at 06:51:10PM +0100, Michael Everson wrote: > A few new additions have been made. See > http://www.unicode.org/iso15924/codechanges.html > > Michael Everson > Registrar Does it mean the "Old North Arabic" will come to unicode soon? Thanks! Petr Tomasek -- Petr Tomasek

Re: CSUR Tonal

2010-07-26 Thread Kent Karlsson
Den 2010-07-26 02.48, skrev "Doug Ewell" : > superscript letters S, T, b, m, r, s, and t. [...] ... > Imagine my surprise, then, when I found that these superscripts are not > formally encoded (only i and n are). [...] There are more superscripted letters than i and n that are encoded; among

Re: CSUR Tonal

2010-07-26 Thread António MARTINS-Tuválkin
On 2010.07.26, 01:48, Doug Ewell wrote: > they be unified with already-encoded Latin superscript letters S, T, b, > m, r, s, and t. <...> > Imagine my surprise, then, when I found that these superscripts are not > formally encoded (only i and n are). Not as superscripts, but as modifiers, onlt