[OT by now] Re: Traditional dollar sign
John Cowan wrote:
> I can't speak for the whole of the last two centuries, but certainly
> current American bills and coins do not use either symbol. The bills
> in common use say ONE DOLLAR, FIVE DOLLARS, TEN DOLLARS, and TWENTY
> DOLLARS; the coins say ONE CENT, FIVE CENTS (the name "nickel" is
> informal), ONE DIME, and QUARTER DOLLAR. The bills are also marked
> using digits.
In my limited experience, that word DIME has done more to confuse
furriners than anything else about the U.S. and Canadian monetary
systems. The dime is the smallest coin in the set physically, weighing
less than half as much as a nickel, and made of (apparently) the same
material, yet worth twice as much. The etymology tracing the word
"dime" back to Latin "decem" ("ten") is lost on those who have not grown
up with the system, and obvious to those who have.
-Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
Re: Traditional dollar sign
. John Cowan wrote, > ... the coins say ONE CENT, FIVE CENTS (the name "nickel" is > informal), ONE DIME, and QUARTER DOLLAR. And HALF DOLLAR and ONE DOLLAR. In 1883, the U. S. Mint changed the design on the five cent piece. The word "CENTS" was omitted from the new design, and the Roman numeral "V" (or, "Ⅴ") was used in place of the digit "5". Unscrupulous people passed gold-plated specimens to unsuspecting individuals as "the new five dollar gold pieces". The U. S. Mint hastily added to word "CENTS" to the design, that very same year. Best regards, James Kass .
Re: Traditional dollar sign
Kevin Brown wrote: > On 27/10/03 3:13 AM, Simon Butcher <[EMAIL PROTECTED]> wrote: > >> I was taught at school that the double-bar form was used when >> Australia switched to decimal currency in 1966, and that it was >> incorrect to write the single-bar form when referring to Australian >> dollars. I guess the single-bar form had taken over due to the lack >> of support from type-faces and computing devices, although it's still >> quite common to see it in Australian publications, especially in >> large fonts (headlines, advertising, etc). > > I was also taught in an Australian school (Queensland) at the time of > our decimal currency chageover, but my experience is exactly the > opposite of Simon's. We were taught to use the single bar form to > distinguish the Australian dollar from the U.S. dollar. Both of these sound like well-intentioned attempts to create a typographical distinction that never really caught on. If either of these conventions had achieved widespread use, both glyphs probably would have made their way into contemporary character sets. This, in turn, would have paved the way for both to be encoded in Unicode, just as U+00A3 POUND SIGN (Â) and U+20A4 LIRA SIGN (â) are both encoded due to artificial glyph distinctions. However, the presence of two opposing conventions serves as a strong hint that there was no consensus in 1966, nor now, as to how glyph variants of the dollar sign were to be used to stand for different types of dollars. Kevin later quoted the Decimal Currency Board: > (c) where it is necessary to distinguish the Australian dollar from > overseas currencies, the letter A should be placed immediately after > the dollar sign - $A;" Interesting. I've often seen the opposite, A$ or AU$, even in contexts that only involved Australian dollars, not U.S. dollars. Of course you can always just use AUD and USD and be done with it. > These specific recommendations were to be read in the context of the > Board's overall recommendations that: > > "It is not considered practicable to prescribe, for all purposes, > exact symbols for dollars and cents, or precise methods of expressing > dollars and cents in words or figures" The European Commission might have chosen to follow this example 30 years later, instead of trying to mandate that the Euro glyph remain invariant in all fonts and contexts. > Incidentally, as far as I know, neither the dollar symbol nor cent > symbol have ever appeared on Australia's paper money or coinage. > > Is this unusual? Not necessarily. As far as I can tell, the cent sign has never been used on any regular-issue U.S. coin. The dollar sign was used occasionally for decoration on large-sized (pre-1929) U.S. currency, but not on small-sized issues (except for the bank-only $100,000 note). Other countries do tend to make greater use of currency symbols on their legal tender. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/
Re: Traditional dollar sign
Kevin Brown scripsit: > Incidentally, as far as I know, neither the dollar symbol nor cent symbol > have ever appeared on Australia's paper money or coinage. > > Is this unusual? I can't speak for the whole of the last two centuries, but certainly current American bills and coins do not use either symbol. The bills in common use say ONE DOLLAR, FIVE DOLLARS, TEN DOLLARS, and TWENTY DOLLARS; the coins say ONE CENT, FIVE CENTS (the name "nickel" is informal), ONE DIME, and QUARTER DOLLAR. The bills are also marked using digits. -- John Cowan http://www.ccil.org/~cowan<[EMAIL PROTECTED]> You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! `Tis a Jute (Finnegans Wake 16.5)
Re: Merging combining classes, was: New contribution N2676
I remembered there was a lot of discussion about this case, which is why I brought it up. Can someone remind me why ZWNBSP would be Bad for this? Wrong RTL coding? (possibly, but it's weak, isn't it) Wrongly indicates a word-break? (this is probably a problem.) ~mark John Hudson wrote: At 04:37 PM 10/26/2003, Jony Rosenne wrote: There is nothing unusual about this. The only problem is that while the Hiriq is between the Lamed and the Mem and belongs to the missing Yod, some people insist that they see two vowels under the Lamed. No, the problem is not the positioning of the hiriq, which is easy to control, but the re-ordering of the hiriq and patah due to the fact that they are in separate combining classes, with the hiriq having a lower number. This is 'a claimed problem', and as should be clear from much previous discussion, far from everyone agrees with your suggestion that the missing Yod be encoded in some way. So this is a live issue, and not one that can simply be ignored because you've made up your mind what you think the solution should be.
Re: Merging combining classes, was: New contribution N2676
At 07:45 PM 10/26/2003, Mark E. Shoulson wrote: I remembered there was a lot of discussion about this case, which is why I brought it up. Can someone remind me why ZWNBSP would be Bad for this? Wrong RTL coding? (possibly, but it's weak, isn't it) Wrongly indicates a word-break? (this is probably a problem.) Yes, ZWNBSP is a word space character; not something one wants in the middle of a word. Functionally, inserting a CGJ here resolves the problem fine. I'm just not convinced that CGJ is a good general solution to the normalisation problem: it works, but it requires deliberate insertion in every place where unwanted mark re-ordering may occur. If I have some free time over the next while, I'll try to figure out just how many places in the Bible text this would be needed: I suspect it is quite a lot. Of course, if you insert automatically CGJ after every mark, you are are sure that re-ordering will not take place, but you also lose any benefit of normalisation. John Hudson Tiro Typeworks www.tiro.com Vancouver, BC [EMAIL PROTECTED] I sometimes think that good readers are as singular, and as awesome, as great authors themselves. - JL Borges
Re: Traditional dollar sign
Further to my earlier reply to Simon Baker about the "correct" symbol for the Australian dollar, the "official" position is documented at http://www.abs.gov.au/Ausstats/[EMAIL PROTECTED]/0/c7103f5100c7663fca2569de00293f3c? OpenDocument. Regarding the currency symbols, the specific recommendation of the Decimal Currency Board were that: "(a) the symbol for the dollar is $ a capital S with two vertical strokes; acceptable alternatives may be used, for example, an S crossed by one vertical stroke; (b) the symbol for the cent is a small letter c; again acceptable alternatives may be used, for example, a c with a stroke through it or some stylised version of the c; (c) where it is necessary to distinguish the Australian dollar from overseas currencies, the letter A should be placed immediately after the dollar sign - $A;" These specific recommendations were to be read in the context of the Board's overall recommendations that: "It is not considered practicable to prescribe, for all purposes, exact symbols for dollars and cents, or precise methods of expressing dollars and cents in words or figures" and, also, "The symbols chosen to express dollars and cents should involve the minimum change to existing printing and other equipment" So it seems that Simon's and my instruction at school were both far more rigid than what was officially intended. Incidentally, as far as I know, neither the dollar symbol nor cent symbol have ever appeared on Australia's paper money or coinage. Is this unusual? Kevin
RE: Merging combining classes, was: New contribution N2676
At 04:37 PM 10/26/2003, Jony Rosenne wrote: There is nothing unusual about this. The only problem is that while the Hiriq is between the Lamed and the Mem and belongs to the missing Yod, some people insist that they see two vowels under the Lamed. No, the problem is not the positioning of the hiriq, which is easy to control, but the re-ordering of the hiriq and patah due to the fact that they are in separate combining classes, with the hiriq having a lower number. This is 'a claimed problem', and as should be clear from much previous discussion, far from everyone agrees with your suggestion that the missing Yod be encoded in some way. So this is a live issue, and not one that can simply be ignored because you've made up your mind what you think the solution should be. John Hudson Tiro Typeworks www.tiro.com Vancouver, BC [EMAIL PROTECTED] I sometimes think that good readers are as singular, and as awesome, as great authors themselves. - JL Borges
RE: Merging combining classes, was: New contribution N2676
There is nothing unusual about this. The only problem is that while the Hiriq is between the Lamed and the Mem and belongs to the missing Yod, some people insist that they see two vowels under the Lamed. Jony > -Original Message- > From: Mark E. Shoulson [mailto:[EMAIL PROTECTED] > Sent: Monday, October 27, 2003 2:07 AM > To: Jony Rosenne > Cc: [EMAIL PROTECTED] > Subject: Re: Merging combining classes, was: New contribution N2676 > > > Jony Rosenne wrote: > > >While the current combining classes may cause some difficulties for > >Biblical scholars (and this isn't cut and dry yet - it isn't certain > >whether these are Unicode problem, implementation problems, missing > >characters or mis-identified characters), I have yet to see > a claimed > >problem with pointed Hebrew - I mean just the points, without > >cantillation marks, as used for non-Biblical texts. And I > don't count > >Microsoft's strange implementation mentioned yesterday as a Unicode > >problem. > > > > > I'll have to recheck, but I think I found, last week, a > Sephardic prayer > book that had, in prayers that were pointed but not cantillated, > "Yerushalayim" spelled without a yod before the final mem. > This may not > be an example of what you're asking for; the prayer in question was > probably Biblical text that wasn't printed with cantillations. > > ~mark > > >
RE: Merging combining classes, was: New contribution N2676
This is, in my opinion, a missing character. Jony > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ted Hopp > Sent: Monday, October 27, 2003 12:53 AM > To: [EMAIL PROTECTED] > Subject: Re: Merging combining classes, was: New contribution N2676 > > > On Sunday, October 26, 2003 3:51 PM, Jony Rosenne wrote: > > > While the current combining classes may cause some difficulties for > > Biblical scholars (and this isn't cut and dry yet - it > isn't certain > > whether these are Unicode problem, implementation problems, missing > > characters or mis-identified characters), I have yet to see > a claimed > > problem with pointed Hebrew - I mean just the points, without > > cantillation marks, as used for non-Biblical texts. > > I assume you mean that you have yet to see a claimed problem > with pointed Hebrew that is based on the combining class > assignments. Otherwise, there is the problem of > distinguishing between vav haluma and holam male, for one. > > Ted > > > Ted Hopp, Ph.D. > ZigZag, Inc. > [EMAIL PROTECTED] > +1-301-990-7453 > > newSLATE is your personal learning workspace >...on the web at http://www.newSLATE.com/ > > > > >
Re: Traditional dollar sign
On 27/10/03 3:13 AM, Simon Butcher <[EMAIL PROTECTED]> wrote: >I was taught at school that the double-bar form was used when Australia >switched to decimal currency in 1966, and that it was incorrect to write >the single-bar form when referring to Australian dollars. I guess the >single-bar form had taken over due to the lack of support from type-faces >and computing devices, although it's still quite common to see it in >Australian publications, especially in large fonts (headlines, >advertising, etc). I was also taught in an Australian school (Queensland) at the time of our decimal currency chageover, but my experience is exactly the opposite of Simon's. We were taught to use the single bar form to distinguish the Australian dollar from the U.S. dollar. Kevin
Re: Merging combining classes, was: New contribution N2676
Jony Rosenne wrote: While the current combining classes may cause some difficulties for Biblical scholars (and this isn't cut and dry yet - it isn't certain whether these are Unicode problem, implementation problems, missing characters or mis-identified characters), I have yet to see a claimed problem with pointed Hebrew - I mean just the points, without cantillation marks, as used for non-Biblical texts. And I don't count Microsoft's strange implementation mentioned yesterday as a Unicode problem. I'll have to recheck, but I think I found, last week, a Sephardic prayer book that had, in prayers that were pointed but not cantillated, "Yerushalayim" spelled without a yod before the final mem. This may not be an example of what you're asking for; the prayer in question was probably Biblical text that wasn't printed with cantillations. ~mark
Re: CGJ - Combining Class Override
On 26/10/2003 01:17, Philippe Verdy wrote: From: "Jony Rosenne" <[EMAIL PROTECTED]> Sorry, Philippe, I had meant a separate character for a "right Meteg", not a separate control character. Does this mean we agree? Jony Yes I agree, but I'm not a Unicode member and have no vote. A separate character with the modified properties does the trick and is more elegant for he long term, but it's not always a general solution when the combining order is more complex than a simple dual choice. I accept that this may be the best way to go from where we are now. But it is not elegant but a nasty kludge. There is but one meteg, in different positions with (apparently) subtly different meanings. Suppose that Unicode had messed things up so that "ea" and "ae" were canonically equivalent. One way to solve that would be to define a second "e", so that "e" before "a" is one character and "e" after "a" is the other (and "e" not next to "a" can be either). That would not be elegant but a nasty kludge. Similarly a second meteg. -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: Merging combining classes, was: New contribution N2676
On 25/10/2003 19:00, Philippe Verdy wrote: From: "Peter Kirk" <[EMAIL PROTECTED]> I can see that there might be some problems in the changeover phase. But these are basically the same problems as are present anyway, and at least putting them into a changeover phase means that they go away gradually instead of being standardised for ever, or however long Unicode is planned to survive for. I had already thought about it. But this may cause more troubles in the future for handling languages (like modern Hebrew) in which those combining classes are not a problem, ... This needs some clarification. Most modern Hebrew is written without any combining marks, or sometimes with just a few scattered ones for specific disambiguation. In such cases the combining classes of Hebrew marks are irrelevant because they never appear in combination. But sometimes, especially in texts for children and language learners, modern Hebrew is written with vowel points, dagesh and sin and shin dots, although not usually accents. In this case, not just in biblical Hebrew, the combining classes ARE a problem, because they imply a canonical order which is illogical as well as hard to render. ... and where the ordering of combining characters is a real bonus that would be lost if combining classes are merged, notably for full text searches where the number of order combinations to search could explode, as the effective order in occurences could become unpredictable for searches. But there is no bonus from the ordering of combining classes, but rather a detrimental effect. Full text searches are already seriously complicated because what is logically one character is split in the canonical order. The relative ordering of sin and shin dot with vowel points leads to a situation equivalent to the French sequence being represented canonically as - except that also a dagesh and a meteg may be inserted between the equivalents of c and cedilla. That is not exactly a bonus if you want to search for the consonant c-cedilla. Yes, the effective order of occurrences could become unpredictable if characters were not entered in the recommended order, i.e. words were misspelled. But that is true in any language: simple searches will not find misspelled words. Of course, if the combining class values were really bogous, a much simpler way would be to deprecate some existing characters, allowing new applications to use the new replacement characters, and slowly adapt the existing documents with the replacement characters whose combining classes would be more language-friendly. This has already been suggested. The problem is the old one that this effectively deprecates all existing pointed Hebrew text, and implementations and fonts based on the current definitions. ... As for requirements that lists are normalised and sorted, I would consider that a process that makes assumptions, without checking, about data received from another process under separate control is a process badly implemented and asking for trouble. Here the problem is that we will not always have to manage the case of separate processes, but also the case of utility libraries: if this library is upgraded separately, the application using it may start experimenting problems. e.g. I am thinking about the implied sort order in SQL databases for table indices: what would happen if the SQL server is stopped just the time to upgrade a standard library implementing the normalization among many other services, because another security bug such as a buffer overrun is solved in another API? When restarting the SQL server with the new library implementing the new normalization, nothing would happen, apparently, but the sort order would no more be guaranteed, and stored sorted indices would start being "corrupted", in a way that would invalidate binary searches (meaning that some unique keys could become duplicated, or not found, producing unpredictable results, critical if they are assumed for, say, user authentication, or file existence). I see the point, but I would think there was something seriously wrong with a database setup which could change its ordering algorithm without somehow declaring all existing indexes invalid. -- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
Re: U+0BA3, U+0BA9
At 02:08 PM 10/25/03 -0700, Doug Ewell wrote: The Unicode character names attempt to be (a) unique and (b) reasonably mnemonic. Anything beyond that is a bonus. They expressly do *not* represent any form of transliteration or transcription scheme. That doesn't mean that some of our conventions aren't based on rules related to various transliteration or transcription schemes. -- Michael Everson * * Everson Typography * * http://www.evertype.com
Re: Merging combining classes, was: New contribution N2676
From: "Peter Kirk" <[EMAIL PROTECTED]> > I see the point, but I would think there was something seriously wrong > with a database setup which could change its ordering algorithm without > somehow declaring all existing indexes invalid. Why would such a SQL engine do so, if what has changed is an external utility library (for example provided by the OS), when the designer had assumed (after reading the Unicode standard), that NF normalizations were assumed to be stable across all backward and forward version of Unicode, and that a previously tested full compliance could be reached by using this external implementation instead of reimplementing it internally the engine itself? Such a change of policy in Unicode would mean a reduced interoperability of existing compliant systems. What is worse, is that distributed systems exchanging data normalized through a common service at one time could experiment later incoherence in the normalization. When I was speaking about full-text search capabilities for example, I meant that the main role of combining classes is not to create grapheme clusters, but to allow handling all canonically equivalent sequences using binary compares instead of requiring constant renormalization to compare all canonically equivalent strings occurences. As all Unicode algorithms are defined to handle canonically equivalent strings the same way so that they will return the same binary results from the same source, modifying the canonical equivalences by merging existing combining classes would in fact affect all standard (or proposed standard) Unicode algorithms, including the most complex ones like collation and text break scanners. We have no choice: - either modifying bogous combining classes and breaking the stability pact for backwards compatibility of normalized strings (at least those containing only characters of the common assigned Unicode subset), - or duplicate existing characters with newer codepoints with modified properties and deprecating (not forbidding) the old ones. - or include in the standard a way to override the combining class order (with CGJ or a new specific and documented CCO control) if it is impossible to deprecate existing characters. I will approve the W3C requirement that really needs that normalized strings in any version of Unicode stay normalized in ALL its versions. For any reason, even if this order is illogical and does not work well with all languistic usages; if it ever causes a problem in a particular language, one has to propose, standardize and use come other character to solve it, but not alter existing ones. After all, that's what has been done since long in Unicode: not all characters are unified, or given a canonical equivalence, even if those characters always use the same glyph. Look for example the Greek characters borrowed in the Latin script or in the Mathematical block: they were kept separate, not unified and not canonically equivalent to preserve the semantic of text using them. Why this "incoherent" status for individual characters would not apply also to combining sequences when there are legitimate reason to deunify them?
Re: Merging combining classes, was: New contribution N2676
On Sunday, October 26, 2003 3:51 PM, Jony Rosenne wrote: > While the current combining classes may cause some difficulties for > Biblical scholars (and this isn't cut and dry yet - it isn't certain > whether these are Unicode problem, implementation problems, > missing characters or mis-identified characters), I have yet to see a > claimed problem with pointed Hebrew - I mean just the points, > without cantillation marks, as used for non-Biblical texts. I assume you mean that you have yet to see a claimed problem with pointed Hebrew that is based on the combining class assignments. Otherwise, there is the problem of distinguishing between vav haluma and holam male, for one. Ted Ted Hopp, Ph.D. ZigZag, Inc. [EMAIL PROTECTED] +1-301-990-7453 newSLATE is your personal learning workspace ...on the web at http://www.newSLATE.com/
Re: U+0BA3, U+0BA9
Michael Everson wrote: >> The Unicode character names attempt to be (a) unique and (b) >> reasonably mnemonic. Anything beyond that is a bonus. They >> expressly do *not* represent any form of transliteration or >> transcription scheme. > > That doesn't mean that some of our conventions aren't based on rules > related to various transliteration or transcription schemes. Well, true, they aren't arbitrary. Obviously there is an attempt to make the names meaningful. But there is no *promise* that a given character name accurately represents a suitable transliteration or transcription of the character. Two examples of this, often cited by Michael, are U+01A2 and U+01A3. That means that if Peter Jacobi discovers a possible anomaly in the character names for Tamil NNA and NNNA -- a question on which I am taking NO STAND WHATSOEVER, by the way -- there is no need to file an erratum on the names. There might be an informative annotation, but that's it. For all the effort UTC and WG2 do make to give correct and meaningful names to characters, there is no guarantee that the occasional OI won't show up, and this is officially not an error in the standard. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/
RE: Merging combining classes, was: New contribution N2676
While the current combining classes may cause some difficulties for Biblical scholars (and this isn't cut and dry yet - it isn't certain whether these are Unicode problem, implementation problems, missing characters or mis-identified characters), I have yet to see a claimed problem with pointed Hebrew - I mean just the points, without cantillation marks, as used for non-Biblical texts. And I don't count Microsoft's strange implementation mentioned yesterday as a Unicode problem. Jony > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Peter Kirk > Sent: Sunday, October 26, 2003 9:37 PM > To: Philippe Verdy > Cc: [EMAIL PROTECTED] > Subject: Re: Merging combining classes, was: New contribution N2676 > > > On 25/10/2003 19:00, Philippe Verdy wrote: > > >From: "Peter Kirk" <[EMAIL PROTECTED]> > > > > > > .. > > >Of course, if the combining class values were really bogous, a much > >simpler way would be to deprecate some existing characters, allowing > >new applications to use the new replacement characters, and slowly > >adapt the existing documents with the replacement characters whose > >combining classes would be more language-friendly. > > > > > This has already been suggested. The problem is the old one that this > effectively deprecates all existing pointed Hebrew text, and > implementations and fonts based on the current definitions. >
Re: U+0BA3, U+0BA9
Doug, Kenneth, All, I', somewhat confused. I assume I'm lacking a lot of background, but I can't interpolate successfully between your answers: "Doug Ewell" <[EMAIL PROTECTED]> wrote: > The Unicode character names attempt to be (a) unique and (b) reasonably > mnemonic. Anything beyond that is a bonus. They expressly do *not* > represent any form of transliteration or transcription scheme. Kenneth Whistler <[EMAIL PROTECTED]> wrote: > The 10646 naming conventions, which are stuck with A-Z for > transliteration, generally use doubled letters to indicate > retroflex consonants, particular for Indic languages. When > a third distinction needs to be made, as for Tamil, the > third name occasionally just gets a tripled letter, as is > the case for U+0BA9. Are UNICODE character names transliterations? Yes, No, Sometimes, Not Officially? Regards, Peter Jacobi -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++
Re: CGJ - Combining Class Override
From: "Jony Rosenne" <[EMAIL PROTECTED]> > Sorry, Philippe, I had meant a separate character for a "right Meteg", not a > separate control character. Does this mean we agree? > > Jony Yes I agree, but I'm not a Unicode member and have no vote. A separate character with the modified properties does the trick and is more elegant for he long term, but it's not always a general solution when the combining order is more complex than a simple dual choice.
RE: U+0BA3, U+0BA9
WG2 had published a guideline to naming characters. Jony > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Doug Ewell > Sent: Saturday, October 25, 2003 11:09 PM > To: Unicode Mailing List > Cc: Peter Jacobi > Subject: Re: U+0BA3, U+0BA9 > > > Peter Jacobi wrote: > > > So, in effect the UNICODE character names attempt to be > > a unified transliteration scheme for all languages? Are these > > principles laid down somewhere or is this more informal? > > The Unicode character names attempt to be (a) unique and (b) > reasonably mnemonic. Anything beyond that is a bonus. They > expressly do *not* represent any form of transliteration or > transcription scheme. > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > >
