Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)
Jim Allan scripsit: What this doesn't indicate is that sometimes in medieval text the ampersand ligature is used to spell _et_ as part of a longer word. Not just mediaeval text; c. for etc. (= et cetera) was common right through the 19th century if not later. -- John Cowan [EMAIL PROTECTED] www.ccil.org/~cowan www.reutershealth.com In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton
Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)
Jim Allan scripsit: See http://www.adobe.com/type/topics/theampersand.html for a short history of the ampersand and some of its variations in modern computer fonts. Unfortunately the explanation of the name ampersand given there is exactly backwards: it is not per se and, but and per se . Anglophones used to recite the alphabet by saying ... x, y, z, and per se [by itself] , pronounced of course and per se and and later ampersand. Check common fonts like Trebuchet MS, Berkeley Book, Goudy Sans, Korinna and Univers for recognizable _Et_ ampersands. I hand-write by making a tall lower-case epsilon glyph and then drawing a solidus over it. -- I am expressing my opinion. When myJohn Cowan honorable and gallant friend is called, [EMAIL PROTECTED] he will express his opinion. This is http://www.ccil.org/~cowan the process which we call Debate. --Winston Churchill
Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)
At 01:21 -0400 2003-07-13, John Cowan wrote: I hand-write by making a tall lower-case epsilon glyph and then drawing a solidus over it. I just use the TIRONIAN SIGN ET. -- Michael Everson * * Everson Typography * * http://www.evertype.com
Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)
John == John Cowan [EMAIL PROTECTED] writes: John Not just mediaeval text; c. for etc. (= et cetera) was John common right through the 19th century if not later. And picked up steam again online in the 1980s; groups.google.com should have lots of examples of c. -JimC
Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)
Michael Everson scripsit: I hand-write by making a tall lower-case epsilon glyph and then drawing a solidus over it. I just use the TIRONIAN SIGN ET. A good choice if you don't slash your DIGIT SEVENs and can make your DIGIT ONEs sufficiently distinct. -- Dream projects long deferredJohn Cowan [EMAIL PROTECTED] usually bite the wax tadpole.http://www.ccil.org/~cowan --James Lileks http://www.reutershealth.com
Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)
John Cowan posted: Not just mediaeval text; c. for etc. (= et cetera) was common right through the 19th century if not later. The combination _c_ is still used. Search for c in http://www.scotland.gov.uk/consultations/environment/tacnh-00.asp for example. But in mentioning medieval use I was thinking of use of the ampersand as a replacement for _et_ in words where _et_ is not the Latin word _et_. An article I read some years back discussed a medieval listing and explanation of the Icelandic alphabet which included the __ as a letter. The author of the article explained this by noting that __ was used occasionally in manuscripts to spell _et_ in Icelandic words. Jim Allan
Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)
At 14:09 -0400 2003-07-13, John Cowan wrote: Michael Everson scripsit: I hand-write by making a tall lower-case epsilon glyph and then drawing a solidus over it. I just use the TIRONIAN SIGN ET. A good choice if you don't slash your DIGIT SEVENs and can make your DIGIT ONEs sufficiently distinct. Eh? I *do* slash my DIGITs SEVEN and I use a single vertical stroke from my DIGITs ONE. The TIRONIAN SIGN ET as used in Ireland has no horizontal stroke. -- Michael Everson * * Everson Typography * * http://www.evertype.com
No UTF-8 in Eudora
Dear all, Apparently, if you are a Eudora user and would to encourage Qualcomm to add proper UTF-8 support to Eudora, you can a request for this option to be included in a future version of Eudora to http://www.eudora.com/developers/feedback/ -- as Eudora 6 is in beta now, perhaps this is a good time to make your opinions known. -- Michael Everson * * Everson Typography * * http://www.evertype.com
Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)
Michael Everson scripsit: A good choice if you don't slash your DIGIT SEVENs and can make your DIGIT ONEs sufficiently distinct. Eh? I *do* slash my DIGITs SEVEN and I use a single vertical stroke from my DIGITs ONE. The TIRONIAN SIGN ET as used in Ireland has no horizontal stroke. I should have said do slash your DIGIT SEVENs. So the glyph in the Unicode 3.0 book is not typical of Irish practice? It seems to have a horizontal stroke all right. -- Where the wombat has walked,John Cowan [EMAIL PROTECTED] it will inevitably walk again. http://www.ccil.org/~cowan
Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)
At 16:21 -0400 2003-07-13, John Cowan wrote: I should have said do slash your DIGIT SEVENs. So the glyph in the Unicode 3.0 book is not typical of Irish practice? It seems to have a horizontal stroke all right. It is utterly typical of Irish practice. I meant that it doesn't have an additional horizontal stroke as a slashed 7 does. -- Michael Everson * * Everson Typography * * http://www.evertype.com
Re: No UTF-8 in Eudora
Would it be opportune to have a list of major commercial software (for various kinds of treatment of text) that do not yet have appropriate support for Unicode / UTF-8? We learned earlier about Quark's lacking in this area. Are there others? Don Osborn Bisharat.net - Original Message - From: Michael Everson [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, July 13, 2003 9:46 PM Subject: No UTF-8 in Eudora Dear all, Apparently, if you are a Eudora user and would to encourage Qualcomm to add proper UTF-8 support to Eudora, you can a request for this option to be included in a future version of Eudora to http://www.eudora.com/developers/feedback/ -- as Eudora 6 is in beta now, perhaps this is a good time to make your opinions known. -- Michael Everson * * Everson Typography * * http://www.evertype.com
Re: No UTF-8 in Eudora
This is also a good thing for non-users to do, if your reason for not using Eudora is lack of Unicode support. (Which is my case.) tex Michael Everson wrote: Dear all, Apparently, if you are a Eudora user and would to encourage Qualcomm to add proper UTF-8 support to Eudora, you can a request for this option to be included in a future version of Eudora to http://www.eudora.com/developers/feedback/ -- as Eudora 6 is in beta now, perhaps this is a good time to make your opinions known. -- Michael Everson * * Everson Typography * * http://www.evertype.com -- - Tex Texin cell: +1 781 789 1898 mailto:[EMAIL PROTECTED] Xen Master http://www.i18nGuy.com XenCrafthttp://www.XenCraft.com Making e-Business Work Around the World -
Re: No UTF-8 in Eudora
Adobe FrameMaker. It desperately needs it. K - Original Message - From: Don Osborn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, July 13, 2003 4:21 PM Subject: Re: No UTF-8 in Eudora Would it be opportune to have a list of major commercial software (for various kinds of treatment of text) that do not yet have appropriate support for Unicode / UTF-8? We learned earlier about Quark's lacking in this area. Are there others? Don Osborn Bisharat.net - Original Message - From: Michael Everson [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, July 13, 2003 9:46 PM Subject: No UTF-8 in Eudora Dear all, Apparently, if you are a Eudora user and would to encourage Qualcomm to add proper UTF-8 support to Eudora, you can a request for this option to be included in a future version of Eudora to http://www.eudora.com/developers/feedback/ -- as Eudora 6 is in beta now, perhaps this is a good time to make your opinions known. -- Michael Everson * * Everson Typography * * http://www.evertype.com
Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)
Philippe Verdy verdy_p at wanadoo dot fr wrote: All this discussion shows that there is an extremely large number of glyph variation for the ampersand which is both (at the abstract level) a symbol character, and a ligature of two lowercase abstract characters. But ligatures for the uppercase ET and titlecase Et do exist as well. For Unicode, only the abstract symbol is encoded, but not the ligatures, despite they share a common set of glyphs. That is one of the essential features of Unicode. Abstract characters are encoded; glyph variants (in general) are not. Could the variant selectors may be used ? I see that Unicode does not allow a free use of variant selectors, which are defined only for cases where it would be important to preserve the precise semantic of the encoded text, but not as a way to preserve the glyphic information (so character variants are strictly limited). That's correct. The difference between the Arial-style glyph that looks a bit like a tilted treble clef (U+1D11E) and John's epsilon-with-solidus and Philippe's e-with-small-attached-t is one of style only. The distinction does not need to be encoded in plain text, any more than the distinction between a lowercase g with one bowl versus two. Apparently the math experts really, really needed to make a distinction in plain text between (e.g.) a less-than-or-equal sign with a horizontal bottom stroke and one with a slanted bottom stroke. We can take it on faith that that distinction is important in plain text, but we don't need to add more distinctions that probably aren't. I don't see a solution for this problem within Unicode itself (and neither in ISO/IEC 10646), unless a separate standard is started to encode glyphs mapped to characters (in the UCS-4 space, out of its 17 first planes?). For now the safest way is to use specific fonts encoding these glyphs in PUA positions, and bind these fonts to the abstract text using stylesheets, meta information, or markup languages. But with such technic, the abstract text would be modified. A way to avoid it is to surround the text with markup that specifies an explicicit substitution, like this in XML: typo as=#xF001;et/typo, You probably don't want to start down the slippery slope of encoding Latin glyph variants as PUA characters. Check the archives of this mailing list; you will find that proposals to use the PUA to turn Unicode into a glyph registry are generally not well received. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/
Re: ISO 639 duplicate codes (was: Re: Ligatures in Turkish and Azeri, was: Accented ij ligatures)
... Of course Java already includes some parts of ICU, but other things are in ICU4J are difficult now to integrate in Java, simply because IBM forgot to modularize ICU so that it can be integrated slowly. Accepting ICU4J as part of the core is a big decision choice, because ICU4J is quite large, and there are certainly developers for Java that would not accept to have 1 aditional MB of data and classes loaded in each JVM (particularly because the integration of ICU would affect a lot of core classes for the Java2 platform now also used for small devices). ... For example, it is impossible to integrate the ICU's Normalizer class in Java without also importing the UChar class and all its related services for UString, such as transliterators, and ... You are very misinformed about ICU4J. Mark __ http://www.macchiato.com Eppur si muove - Original Message - From: Philippe Verdy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 12, 2003 14:45 Subject: Re: ISO 639 duplicate codes (was: Re: Ligatures in Turkish and Azeri, was: Accented ij ligatures) On Saturday, July 12, 2003 4:17 PM, Jony Rosenne [EMAIL PROTECTED] wrote: What has iw to with Hebrew? I wasn't involved with the change, but I'm glad it was done. Java and other systems probably still use it because they never bothered to check the latest version of 639. I know for certain that this was the case with one of the major computer vendors. In the case of Java, I don't think so. Sun has certainly maintained the language code simply to avoid breaking existing localizations to Hebrew of Java-written software, waiting probably for a better way to locate locales than the fixed locales path resolution algorithm which is part of its core Classes since the beginning. As long as Java core classes will not use a locale resolver that allows tuning the resolution algorithm used to load resource bundles, while also maintaining the compatibility with the existing softwares that assume that Hebrew resources are loaded with the iw language code, Sun will not change this code. In IBM ICU4J, there is such an extended resolver, but Sun takes a long time to approve such proposals, and have it first accepted, documented, balloted and voted in its JCP program. Of course Java already includes some parts of ICU, but other things are in ICU4J are difficult now to integrate in Java, simply because IBM forgot to modularize ICU so that it can be integrated slowly. Accepting ICU4J as part of the core is a big decision choice, because ICU4J is quite large, and there are certainly developers for Java that would not accept to have 1 aditional MB of data and classes loaded in each JVM (particularly because the integration of ICU would affect a lot of core classes for the Java2 platform now also used for small devices). For example, it is impossible to integrate the ICU's Normalizer class in Java without also importing the UChar class and all its related services for UString, such as transliterators, and advanced features such as the UCA tailoring rules run-time compiler. Some ICU open-sourcers, as well as its users seem to think now that the modularization of ICU is an important but complex project. -- Philippe. Spams non tolrs: tout message non sollicit sera rapport vos fournisseurs de services Internet.
