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
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
Thanks Kenneth Whistler and Mark Davis. That clarifies the situation.
--
Shriramana Sharma
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
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
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
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
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
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
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
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
"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
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
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
> 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
"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
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
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.
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
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
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
21 matches
Mail list logo