Philippe said:
> Interesting: these arabic symbols are proposed, but with strange names.
> I understand that these diacritics are needed to fit with their character
> properties (notably in BiDi contexts).
>
> 0659 ARABIC ZWARAKAY . Pashto
> Why not ARABIC MACRON ? Well, Zwarakay may be appro
From: "Michael Everson" <[EMAIL PROTECTED]>
> A new contribution:
> N2676
> Repertoire additions from meeting 44
> Asmus Freytag
> 2003-10-23
> http://www.dkuug.dk/jtc1/sc2/wg2/docs/n2676.pdf
Interesting: these arabic symbols are proposed, but with strange names.
I understand that these diacriti
From: "Doug Ewell" <[EMAIL PROTECTED]>
> Jill Ramonsky wrote:
>
> > Here's a better idea.
> > Let's just stick with the idea that ANY C0 or C1 control has no place
> > being anywhere in a line of text, and so any sequence of one or more
> of
> > them will be interpretted as a line-break!
>
> Tab
On 24/10/2003 11:44, Michael Everson wrote:
That character is a variant of the as-yet unencoded CYRILLIC CAPITAL
LETTER KU, which is very often otherwise displayed as Q. It is a big q
shape.
In what other languages is or was it used? Kurdish? Anything else?
--
Peter Kirk
[EMAIL PROTECTED] (pers
Peter Jacobi asked:
> Can someone clarify the status of
> U+0BA3 TAMIL LETTER NNA and
> U+0BA9 TAMIL LETTER NNNA
>
> Comparing the glyph shapes with TSCII character tables
> it is quite clear that U+0BA3 is NNNA and U+0BA9 is NNA.
>
> This makes also a lot of sense for non-speakers of Tamil,
>
At 20:41 +0200 2003-10-24, Peter Jacobi wrote:
This makes also a lot of sense for non-speakers of Tamil, because it
correctly correlates the number of 'N's to the number of loops in
the glyph.
The transliteration in the naming convention is unrelated to this. In
any case names cannot be changed
That character is a variant of the as-yet unencoded CYRILLIC CAPITAL
LETTER KU, which is very often otherwise displayed as Q. It is a big
q shape.
--
Michael Everson * * Everson Typography * * http://www.evertype.com
Dear All,
Can someone clarify the status of
U+0BA3 TAMIL LETTER NNA and
U+0BA9 TAMIL LETTER NNNA
Comparing the glyph shapes with TSCII character tables
it is quite clear that U+0BA3 is NNNA and U+0BA9 is NNA.
This makes also a lot of sense for non-speakers of Tamil,
because it correctly correla
A new contribution:
N2676
Repertoire additions from meeting 44
Asmus Freytag
2003-10-23
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n2676.pdf
--
Michael Everson * * Everson Typography * * http://www.evertype.com
At 02:05 PM 10/24/03 +0100, Jill Ramonsky wrote:
Here's a better idea.
Let's just stick with the idea that ANY C0 or C1 control has no place
being anywhere in a line of text, and so any sequence of one or more of
them will be interpretted as a line-break!
Sorted once and for all!
I'm not sure you
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Peter Kirk
> See also
> http://www.gutenberg.eu.org/pub/GUTenberg/publicationsPDF/28-29-
> berdnikovb.pdf,
> which incidentally mentions at least two Cyrillic letters not in
Unicode
> (top of p.34), the
The Business section in today's San Jose Mercury News (Friday, Oct. 24) has a story on
Unicode and the Script Encoding Initiative:
http://www.bayarea.com/mld/mercurynews/business/7092371.htm
(The full article is available on the Web for a limited time.)
Deborah Anderson
Researcher, Dept. of Lin
> For completeness the definitions of \n and \r in C are:
>
> "\n (new line) Moves the active position to the initial
> position of the next line.
Hmm. If the output is to a terminal, and the OS is Unixy,
then to guarantee that behaviour, \n must generate both
a CR and an LF, not just an LF. T
Jill Ramonsky wrote:
> Here's a better idea.
> Let's just stick with the idea that ANY C0 or C1 control has no place
> being anywhere in a line of text, and so any sequence of one or more
of
> them will be interpretted as a line-break!
Tab?
-Doug Ewell
Fullerton, California
http://users.adelp
From: "Marco Cimarosti" <[EMAIL PROTECTED]>
> I thought the chart was intended as a rationale for prioritizing the
support
> of languages in consideration of the profitability of the corresponding
> markets:
>
> 1. support for Western languages is priority one, as it corresponds to the
> largest sl
From: "Stefan Persson" <[EMAIL PROTECTED]>
> Stephane Bortzmeyer wrote:
>
> > I do not agree. It would mean *each* application has to normalize
> > because it cannot rely on the kernel. It has huge security
> > implications (two file names with the same name in NFC, so visually
> > impossible to d
On 24/10/2003 04:27, Anto'nio Martins-Tuva'lkin wrote:
On 2003.10.23, 23:19, Peter Kirk <[EMAIL PROTECTED]> wrote:
the V-shaped letter is something like the Russian close central vowel
? - might be U+0474 which was used in Russian up to about that time,
Iz^ica, of course! I mean, it may b
On Fri, 24 Oct 2003 01:58:03 -0700 (PDT), "Andrew C. West" wrote:
>
> Try BabelPad at uk.geocities.com/BabelStone1357/Software/BabelPad.html
>
> Select the text, and click on "Convert : NCR to Unicode" from the menu.
> Or simply check the "Convert NCRs" checkbox on the file open dialog when you
Philippe Verdy scripsit:
> > On Mac Classic,
> > \n is 15, and on EBCDIC systems, it's also 15, though for a different
> > reason.
>
> Correction: On Mac Classic and in EBCDIC, \n is 015 (or 13), not 15:
> please don't mix in the same sentence the decimal,
> and octal notations.
It's worse than
From: <[EMAIL PROTECTED]>
> > > Still, I stand by saying that \n is defined in C++ as LF and \r as CR,
> > because
> > > that's sitting in front of me in black and white.
> >
> > Yes, true. But that does *not* mean that (int)'\n' can be counted on to
> > be 10
>
> Of course, given that any of a v
Wow!
I'm starting to think that Linux and Java have it right. Just use one
character. Keep it the same throughout. Sorted.
But ... oh ... then you still have to convert to CRLF when you send it
over the internet as emal. Damn!
Here's a better idea.
Let's just stick with the idea that ANY C0 or C
From: "John Cowan" <[EMAIL PROTECTED]>
> > Still, I stand by saying that \n is defined in C++ as LF and \r as CR,
because
> > that's sitting in front of me in black and white.
>
> Yes, true. But that does *not* mean that (int)'\n' can be counted on to
> be 10, any more than (int)'a' can be counte
On 2003.10.23, 23:19, Peter Kirk <[EMAIL PROTECTED]> wrote:
> the V-shaped letter is something like the Russian close central vowel
> ? - might be U+0474 which was used in Russian up to about that time,
Iz^ica, of course! I mean, it may be something else though, but it is
unforgivable that I hadn
On 2003.10.23, 21:08, Michael Everson <[EMAIL PROTECTED]> wrote:
> At 12:53 -0700 2003-10-23, Peter Constable wrote:
>
>>> - Reversed sigma -- is it a variant of U+01B7 : LATIN CAPITAL LETTER
>>> EZH?
>>
>> This typeform is used in Ghana, and for that context I concluded that
>> it is a variant
> > Still, I stand by saying that \n is defined in C++ as LF and \r as CR,
> because
> > that's sitting in front of me in black and white.
>
> Yes, true. But that does *not* mean that (int)'\n' can be counted on to
> be 10
Of course, given that any of a variety of character encodings could be i
[EMAIL PROTECTED] scripsit:
> However, under closer examination we are both wrong. '\u000A' is not allowed!
Fair enough. Banning low-valued \u and \U escapes allows \u and \U
removal to be done at a very low level. Java in effect has the same
rule: it is legal to say '\u000A', but that is equiv
> > -Original Message-
> > Date/Time:Tue Oct 21 07:54:01 EDT 2003
> > Contact: [EMAIL PROTECTED]
> > Report Type: Other Question, Problem, or Feedback
> >
> > Hello Unicode-Team,
> >
> > i'm looking for a tool or a tutorial to convert japanese
> > signs in numeric unicode signs (e
Quoting John Cowan <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] scripsit:
>
> > But if ('\n'=='\u000A') should always be true, because ISO 14882 defines \n
> as
> > LF and defines \u as "that character whose short name in ISO/IEC 10646
> is
> > " and the character whose short name in IS
On Thu, 23 Oct 2003 13:05:05 -0700, Peter Lofting wrote:
>
> The representation of slashed digits are problematic for two reasons.
>
> (1) The notation is that a slash indicates half of the value. This is
> different to the "less a half" interpretation Andrew describes, which
> would only be tr
> > i'm looking for a tool or a tutorial to convert japanese
> > signs in numeric unicode signs (e.g. 留). Can you help me?
> >
Try BabelPad at uk.geocities.com/BabelStone1357/Software/BabelPad.html
Select the text, and click on "Convert : NCR to Unicode" from the menu.
Or simply check the "Con
30 matches
Mail list logo
