Den 2010-07-26 02.48, skrev Doug Ewell d...@ewellic.org:
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
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
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 *
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
Luke-Jr luke at dashjr dot org 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
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
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 *work*. So
There are 857 combining marks with combining class of 0:
http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[[:M:]%26[:ccc%3D0:]]abb=ong=
On Sat, Jul 24, 2010 at 11:25 AM, Philippe Verdy verd...@wanadoo.fr wrote:
Kent Karlsson kent.karlsso...@telia.com wrote:
Den 2010-07-24 10.07, skrev
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
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
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
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 hidden
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.
Thanks Kenneth Whistler and Mark Davis. That clarifies the situation.
--
Shriramana Sharma
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
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
16 matches
Mail list logo
