Re: Text Editors and Canonical Equivalence (was Coloured diacriti cs)

Peter Kirk wrote: >> The "wcslen" has nothing whatsoever to do with the Unicode standard, >> but it has all to do with the *C* standard. And, according to the C >> standard, "wcslen" must simply count the number "wchar_t" array >> elements from the location pointed to by its argument up to the fi

Re: XML based mapping files.

Shubhagam Gupta wrote: > I am trying to Implement Unicode Technical Report, UTR 22 and I have > a few questions about this specification. Since this specification is > normative, XML must be the way to go when including local encoding to > unicode mapping files in your application, this requires c

Re: Glottal stops (bis) (was RE: Missing African Latin letters (bis))

On 12/09/03 02:26, Peter Constable wrote: From: [EMAIL PROTECTED] on behalf of Kenneth Whistler Nobody is agitating for an uppercase apostrophe. Not in Canada, that I know of. (I've seen indication of languages in Russia that have a case distinction for ' and possible also ".) Early ve

Re: Qumran Greek

Elaine in central Texas Hi, > I would guess that the first of your symbols, if > Greek, is a PARAGRAPHOS or a FORKED PARAGRAPHOS. > It's also used in Coptic. Yes, both of those seem to be at Qumran. In Coptic, do you know what period of time they are in? > The X looks like a CHI of cour

RE: Qumran Greek

At 00:27 +0100 2003-12-10, Philippe Verdy wrote: It's exactly similar to annotating today a Han text with notes in English. So I'm not sure it needs a specific encoding, as this may just be a shift from one script to another. Of course the PARAGRAPHOS characters are to be encoded in the Supplement

RE: Qumran Greek

I have no problem with Qumran scribes being multilingual or using Greek symbols in either Coptic or Hebrew or Aramaic text. -- Michael Everson * * Everson Typography * * http://www.evertype.com

RE: Qumran Greek

Michael Everson wrote: > At 13:34 -0800 2003-12-08, Elaine Keown wrote: > >I include 2 Qumran symbols that are probably Greek. > > Obviously it's impossible to tell from two tiny gifs > > >I'm looking for help with the large 'X'. > > I would guess that the first of your symbols, if Greek, is

Re: Qumran Greek

At 13:34 -0800 2003-12-08, Elaine Keown wrote: I include 2 Qumran symbols that are probably Greek. Obviously it's impossible to tell from two tiny gifs I'm looking for help with the large 'X'. I would guess that the first of your symbols, if Greek, is a PARAGRAPHOS or a FORKED PARAGRAPHOS. It

RE: unification (CJKV history) ; Alphabetic Aramaic+ ...

At 14:07 -0800 2003-12-09, Elaine Keown wrote: I'm looking for previous thought on properties of scripts that affect how they are encoded Properties? I think that encoding standards are actually the technical end of what they call "sociolinguistics" in linguistics dept + discussing a scrip

XML based mapping files.

Hello,     I am trying to Implement Unicode Technical Report, UTR 22 and I have a few questions about this specification. Since this specification is normative, XML must be the way to go when including local encoding to unicode mapping files in your application, this requires conv

RE: unification (CJKV history) ; Alphabetic Aramaic+ ...

Elaine Keown still in Texas Dear Tom Emerson: > > This history of unification is laid out pretty > > clearly in Appendix A of TUS. I hope this is online--And they go all the way back to the 200 previous suggestions, some from the Chinese Language Computer Society? > "A Compu

RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

> Just imagine what would be created with your assumption with this source: > const wchar_t c = L'?'; > where ? is a combining character. The programmer would get bit. At best, there's no reason to assume that every compiler accepts UTF-8, besides that fact that you can't assume that the co

RE: unification (CJKV history) ; Alphabetic Aramaic+ ...

> I'm working on unification and would like to more > about the earliest CJKV work--was it from the RLG? This history of unification is laid out pretty clearly in Appendix A of TUS. > I read a book on computerizing languages by a Sproat > from Bell Labs--not as satisfying as I had hoped, > althou

unification (CJKV history) ; Alphabetic Aramaic+ ...

Elaine in Texas Hi, I'm working on unification and would like to more about the earliest CJKV work--was it from the RLG? Was their work the 201st solution to Chinese, or linked to the 200 earlier proposals? I read a book on computerizing languages by a Sproat from Bell Labs--not as s

RE: Glottal stops (bis)

Peter Constable posted: Michael, you've seen what they are using. How will the community be served when type designers start creating fonts that have a cap-height glyph for 0294 supplemented by a modified capital P? The characters can be seen on the web at http://www.wkss.nt.ca/HTML/08_Projects

Re: Text Editors and Canonical Equivalence (was Coloured diacritics)

On 09/12/2003 10:41, [EMAIL PROTECTED] wrote: Peter Kirk scripsit: ... (otherwise a normalizer would be impossible; it wouldn't know whether to normalize or not!) ... Not so. Normalisation is idempotent Quite right. I should have said that normalization *checking* would be imposs

RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

[EMAIL PROTECTED] writes: > > > You might as well say that C code is not plain text because it too is > > > subject to special canons of interpretation. > > > > C, C++ and Java source files are not plain text as well (they > > have their own > > C, C++ and Java source files are plain text. > >

Re: Text Editors and Canonical Equivalence (was Coloured diacriti cs)

On 09/12/2003 10:22, Marco Cimarosti wrote: Peter Kirk wrote: So, should n equal four or five? The answer would appear to depend on whether or not the source file was saved in NFC or NFD format. No, surely not. If the wcslen() function is fully Unicode conformant, it should give the sa

Re: [OT]

At 11:06 -0800 2003-12-09, John Hudson wrote: At 06:54 AM 12/9/2003, Michael Everson wrote: Hm. We have a hot beverage symbol. Maybe we need a pint glass ... and combining shamrock and harp marks. I did get the shamrock in. ;-) -- Michael Everson * * Everson Typography * * http://www.evertype

Re: [OT]

At 06:54 AM 12/9/2003, Michael Everson wrote: Hm. We have a hot beverage symbol. Maybe we need a pint glass ... and combining shamrock and harp marks. JH Tiro Typeworks www.tiro.com Vancouver, BC [EMAIL PROTECTED] What was venerated as style was nothing more than an imper

Unsubscribe

begin:vcard n:Adhav;Mahesh tel;cell:609.468.7005 tel;work:732.227.7720 x-mozilla-html:FALSE org:PRI;PD Informatics adr:;;;New Brunswick;NJ;;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Consultant fn:Mahesh C Adhav end:vcard

Unsubscribe

RE: [OT]

> [...] > some greedy investors turned it into a scam just for a quick buck (for > surely it will be quick!) > > Sorry, I had to get that off my chest. Hopefully someone > with some pull in Ireland will read this and do something > about it :-) Or simply flush Guinne$$ and drink Murphix. :-) C

Re: Text Editors and Canonical Equivalence (was Coloured diacritics)

Peter Kirk scripsit: > >... (otherwise a normalizer > >would be impossible; it wouldn't know whether to normalize or not!) ... > > > Not so. Normalisation is idempotent Quite right. I should have said that normalization *checking* would be impossible. -- Only do what only you can do.

Re: Text Editors and Canonical Equivalence (was Coloured diacritics)

On 09/12/2003 10:16, [EMAIL PROTECTED] wrote: Peter Kirk scripsit: No, surely not. If the wcslen() function is fully Unicode conformant, it should give the same output whatever the canonically equivalent form of its input. Not so. Remember, the conformance requirement is not that a pro

Unsubscribe

RE: Text Editors and Canonical Equivalence (was Coloured diacriti cs)

Peter Kirk wrote: > > So, should n equal four or five? The answer would appear to > > depend on whether or not the source file was saved in NFC > > or NFD format. > > > No, surely not. If the wcslen() function is fully Unicode > conformant, it should give the same output whatever the > canonicall

Re: Overload (was Re: Text Editors and Canonical Equivalence (was Coloured diacritics))

On 09/12/2003 10:01, Mark Davis wrote: No, surely not. If the wcslen() function is fully Unicode conformant, it should give the same output whatever the canonically equivalent form of its input. That more or less implies that it should normalise its input. No, that is not a requirement of Uni

RE: Text Editors and Canonical Equivalence (was Coloured diacriti cs)

I (Marco Cimarosti) wrote: > > So, should n equal four or five? > > Why not six? ^^^ Errata: "seven". > If, in our C(++) compiler, type "wchar_t" is an alias for > "char", and "wide character strings" are encoded in UTF-8, > and the "é" is decomposed, then n will be equal to 6.

RE: Text Editors and Canonical Equivalence (was Coloured diacriti cs)

> Hmm. Now here's some C++ source code (syntax colored as > Philippe suggests, to imply that the text editor understands > C++ at least well :enough to color it) > > int n = wcslen(L"café"); > > (That's int n = wcslen(L"café"); for those without HTML email) > > The L prefix on a string literal

Re: plain text (was RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

Peter Constable scripsit: > Perhaps we need some new terminology here. It might be helpful to > describe an XML file as a "plain-text-markup file" (PTM, for acronym > lovers), but reserve the term "plain text file" for files that contain > text with no markup. Note that the terms being defined are

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

On 09/12/2003 06:36, [EMAIL PROTECTED] wrote: Perhaps so does yours. It isn't clear whether the CSS for .red-text would have to over-ride the default behaviour whereby an inline element like is rendered by stacking it to the left or right (depending on text directionality) of the previous inli

Unsubscribe

  - The information contained in this message is proprietary of Amdocs, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient

Re: Text Editors and Canonical Equivalence (was Coloured diacritics)

Peter Kirk scripsit: > No, surely not. If the wcslen() function is fully Unicode conformant, it > should give the same output whatever the canonically equivalent form of > its input. Not so. Remember, the conformance requirement is not that a process can't distinguish between canonically equiv

Overload (was Re: Text Editors and Canonical Equivalence (was Coloured diacritics))

> No, surely not. If the wcslen() function is fully Unicode conformant, it > should give the same output whatever the canonically equivalent form of > its input. That more or less implies that it should normalise its input. No, that is not a requirement of Unicode conformance. BTW, I must confess

Re: [OT]

> It staggers the imagination to conceive of how this could happen. Real > Irish Guinness was a constant in this world for centuries, and suddenly > some greedy investors turned it into a scam just for a quick buck (for > surely it will be quick!) There has always been variation in the way it was

RE: Glottal stops (bis) (was RE: Missing African Latin letters (bis))

Doh! (It was late.) > -Original Message- > From: Curtis Clark [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 09, 2003 8:00 AM > To: Peter Constable > Subject: Re: Glottal stops (bis) (was RE: Missing African Latin letters (bis)) > > on 2003-12-08 23:40 Peter Constable wrote: > > If

Re: Text Editors and Canonical Equivalence (was Coloured diacritics)

On 09/12/2003 07:00, Arcane Jill wrote: Hmm. Now here's some C++ source code (syntax colored as Philippe suggests, to imply that the text editor understands C++ at least well :enough to color it) int n = wcslen(L"café"); (That's int n = wcslen(L"café"); for those without HTML email) The L

plain text (was RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of [EMAIL PROTECTED] > XML files most certainly are plain text XML *can* be interpreted as plain text, or it can be interpreted as something *other* than plain text (i.e. XML). This ambiguity exists for any other plain-text-based ma

Re: [OT]

[EMAIL PROTECTED] wrote: > Stout was indeed given as a health drink in small doses in certain > cases, it's one of the few foods that are a good source of both iron and > calcium. However the only doctor I've heard of recommending it in recent > years was... > I know of an (Irish) obstetrician in

RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

From: Philippe Verdy [mailto:[EMAIL PROTECTED] >> I see no particular value in this. The font rendering of base >> diacritic should be exactly the same as that for >> basediacritic provided the font >> characteristics are the same or do not affect metrics. > >This is wrong here: there's no guaran

Re: Text Editors and Canonical Equivalence (was Coloured diacritics)

Arcane Jill wrote: > The intention of canonical equivalence is that the glyphs should > display the same - otherwise we'd need precomposed versions of, well, > everything. The intention of canonical equivalence is that *all* operations that involve "interpreting" the text treat two canonically eq

RE: Glottal stops (bis) (was RE: Missing African Latin letters (bis))

At 23:40 -0800 2003-12-08, Peter Constable wrote: From: [EMAIL PROTECTED] on behalf of Michael Everson >>to use the kinds of uppercase >>glyph models used in similar instances of after-the-fact >>uppercase inventions based on IPA or other phonetic >>alphabets and usages. > A modified capital

RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

> > You might as well say that C code is not plain text because it too is > > subject to special canons of interpretation. > > C, C++ and Java source files are not plain text as well (they have their own C, C++ and Java source files are plain text. > "text/*" MIME type, which is NOT "text/plain"

Re: Transcoding Tamil in the presence of markup (was Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup))

I agree strongly. Reordering of glyphs doesn't affect the ability to maintain styles. Every reasonable package has to retain the mappings back and forth between character and glyph to maintain styles and to map highlighting/mouse clicks/etc. The only issue is for combinations. That is, the characte

Re: Ideographic Description Characters

On Dec 8, 2003, at 6:20 PM, Mark Davis wrote: John, I don't see why you are saying that it is a 'no-no'. There is no reason that someone couldn't do something like that. Strictly speaking, it isn't in violation of TUS, which only says (p. 309), "Ideographic Description Sequences are not to be

RE: Text Editors and Canonical Equivalence (was Coloured diacritics)

Hmm. Now here's some C++ source code (syntax colored as Philippe suggests, to imply that the text editor understands C++ at least well :enough to color it) int n = wcslen(L"café"); (That's int n = wcslen(L"café"); for those without HTML email) The L prefix on a string literal makes it a wide

RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

> You might as well say that C code is not plain text because it too is > subject to special canons of interpretation. C, C++ and Java source files are not plain text as well (they have their own "text/*" MIME type, which is NOT "text/plain" notably because of the rules associated with end-of-line

Re: [OT]

At 12:44 + 2003-12-09, [EMAIL PROTECTED] wrote: A pint of plain's your only man. Yes, yes, yes, now will you people start talking about fragile-glass symbols or plate-and-cutlery symbols or something and drag this back into some semblance of topicality? Hm. We have a hot beverage symbol. Ma

Re: Transcoding Tamil in the presence of markup (was Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup))

On Mon, 8 Dec 2003, Peter Jacobi wrote: > It would be most interesting, if someone can point out a wordprocessor > or even a rendering library (shouldn't Pango be the solution to > everything?), > which enables styling of individual Tamil letters. I think Pango's attributed string ( http://de

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

> Your alternative suggestion using svg seemed to require the user to > handle the details of glyph positioning with specified horizontal > advances, which is surely a very strange requirement. Or maybe I have > misunderstood what was going on here. Perhaps so does yours. It isn't clear whether

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

On 09/12/2003 05:13, [EMAIL PROTECTED] wrote: So, let's get this clear. Within an XML or HTML document, if I want an e with a red acute accent on it, it is quite permissible to write: e{U+0301} where {U+0301} is replaced by the actual Unicode character, and "red-text" is defined in the stylesh

Re: [OT]

On 09/12/2003 04:44, [EMAIL PROTECTED] wrote: Despite your French notice about danger to the health (not to the sanity, though that might be true, too), Guinness was actually introduced as a health drink. I think the problem was that too many Irish people were spending their money on whiskey an

RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

[EMAIL PROTECTED] writes: > Philippe Verdy scripsit: > > XML files are definitely NOT plain text (if this was the case, > > then it would be forbidden to interpret "<" as a special markup > > character instead of the standard Unicode base character with > > its associated glyph)... > > You migh

RE: [OT]

[EMAIL PROTECTED] wrote: > Stout was indeed given as a health drink in small doses in > certain cases, it's one of the few foods that are a good > source of both iron and calcium. However the only doctor > I've heard of recommending it in recent years was a bone > specialist who was trained in

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

Hi Peter, All, Peter Kirk <[EMAIL PROTECTED]> wrote: > [...] > [About é being correct HTML} > [...] > If this is correct, then the Tamil problem which Peter J is concerned > about has gone away completely, or at least it is reduced to a tricky > rendering issue. Jungshik and Martin already vot

Re: New symbols (was Qumran Greek)

> > is > > a complete listing of new symbols to go into Unicode > > Thanks!--how many Web sites do you all have? http://www.evertype.com/formal.html is a good link to what Michael Everson is doing. is an

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

Philippe Verdy scripsit: > XML files are definitely NOT plain text (if this was the case, then it would > be forbidden to interpret "<" as a special markup character instead of the > standard Unicode base character with its associated glyph)... You might as well say that C code is not plain text

RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

> -Message d'origine- > De : Peter Kirk [mailto:[EMAIL PROTECTED] > Envoye : mardi 9 decembre 2003 13:17 > A : [EMAIL PROTECTED] > Cc : [EMAIL PROTECTED] > Objet : Re: Coloured diacritics (Was: Transcoding Tamil in the presence > of markup) > > > On 09/12/2003 03:41, Philippe Verdy wrot

RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

[EMAIL PROTECTED] writes: > What is not allowed, and this makes XML technically non-conformant to the > Unicode Standard Where did you see that XML files need to be conformant to the Unicode standard? XML files are definitely NOT plain text (if this was the case, then it would be forbidden to int

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

> So, let's get this clear. Within an XML or HTML document, if I want an e > with a red acute accent on it, it is quite permissible to write: > > e{U+0301} > > where {U+0301} is replaced by the actual Unicode character, and > "red-text" is defined in the stylesheet. So it is not a problem that

Re: [OT]

> Despite your French notice about danger to the health (not to the > sanity, though that might be true, too), Guinness was actually > introduced as a health drink. I think the problem was that too many > Irish people were spending their money on whiskey and not eating well, > so Arthur Guinnes

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

Philippe Verdy scripsit: > When in doubt, don't perform any normalization of XML _files_ as they are > NOT plain text: you need a XML parser to do it safely only in relevant > sections of this file. All you could do safely is to possibly reencode XML > files (for example from UTF-8 to UTF-16 encod

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

> Anyone, please, is it or is it not true that XML forbids, or will forbid > in future versions, combining characters immediately after markup? XML does not forbid it, it does recommend you avoid it. Charmod defines "include-normalization" and "full-normalization" which go beyond Unicode normal

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

Peter Kirk scripsit: > Anyone, please, is it or is it not true that XML forbids, or will forbid > in future versions, combining characters immediately after markup? XML 1.0 is silent on the subject. The W3C Character Model (which is not official yet) says that "content developers SHOULD avoid c

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

On 09/12/2003 03:41, Philippe Verdy wrote: Peter Kirk writes: Philippe, you have now stated this (several times). But just a day earlier you yourself stated that the rule forbidding combining marks at the start of a string would never be relaxed because it is fundamental to the XML containme

Re: [OT]

On 08/12/2003 17:29, Philippe Verdy wrote: ... Nota: when speaking about alcohol in public areas, we have to add here in France a mandatory legal notice: "L'abus d'alcool est dangereux pour la sante, appreciez et consommez le avec moderation." ... Despite your French notice about danger to the

RE: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

Peter Kirk writes: > Philippe, you have now stated this (several times). But just a day > earlier you yourself stated that the rule forbidding combining marks at > the start of a string would never be relaxed because it is fundamental > to the XML containment model. You don't usually contradict

Re: Transcoding Tamil in the presence of markup (was Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup))

On 08/12/2003 16:17, Kenneth Whistler wrote: ... Having an 'invisible consonant' to call for rendering of the vowel sign in isolation (and without the dotted circle), would also help the limited number of cases where the styled single character is needed - but in a rather hackish way. That i

Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup)

On 08/12/2003 15:51, Philippe Verdy wrote: ... Peter Kirk writes: Agreed. But now we are told that the latter is illegal XML because a combining mark is not permitted (by XML, not by Unicode) after . It is not forbidden by XML. It's just that handling a XML file (which is not plain-text)

RE: Transcoding Tamil in the presence of markup (was Re: Coloured diacritics (Was: Transcoding Tamil in the presence of markup))

From: [EMAIL PROTECTED] on behalf of Kenneth Whistler >> Unicode doesn't prevent styling, of course. But having 'logical' order >> instead of 'visual' makes it a hard task for the application and the >> renderer. >> This is witnessed by the thin-spread support for this. > >Yes... Ken conceded th

RE: Glottal stops (bis) (was RE: Missing African Latin letters (bis))

From: [EMAIL PROTECTED] on behalf of Michael Everson >>to use the kinds of uppercase >>glyph models used in similar instances of after-the-fact >>uppercase inventions based on IPA or other phonetic >>alphabets and usages. > >A modified capital P would probably do. [??!!] Michael, you've seen wh

RE: New symbols (was Qumran Greek)

>> and why >> aren't they linked together for us fringies? > >They are... For some reason, my first thought was of Ford Prefect asking the fellow regarding the not-well-publicized plans to build a by-pass, "Have you ever thought of going into advertizing? "-) >No, it is made from the Riv

RE: Glottal stops (bis) (was RE: Missing African Latin letters (bis))

From: [EMAIL PROTECTED] on behalf of Kenneth Whistler >Athabascan languages in Canada are also written with >practical orthographies such as these At least two of which (Dogrib and one or both varieties of Slavey) use a cased glottal stop, not U+0027. >Nobody is agitating for an uppercase >