RE: current version of unicode-font
Subject: RE: current version of unicode-font On Thu, 2 Dec 2004 at 07:51:42 -0800, Peter Constable wrote: The most recently shipped version is 1.01, which ships with Office 2003. ... and Office 2004 doesn't ship with Arial Unicode MS at all! Kevin
Spammed by a list member!
On Monday, 29 November 2004 at 8:52 AM, Dean Snyder wrote: You are getting this email directly because Rick McGowan, the moderator of the Unicode email list, sent me the following response concerning my attempt to post the appended message to the Unicode email list: All threads on Phoenician have been closed on this mail list. -- Sarasvati Personal email traffic could be avoided if we were merely allowed to discuss this legitimate and timely Unicode issue on the Unicode email list. In particular I would like responses from members of the Unicode list to the 3 questions I raise in light of the German DIN rejection of a separate encoding for Phoenician. [The recipients of this email are merely some of those whose names I recognize from reading their posts to the Unicode email list in 2003 or 2004.] Dear Dean I personally have not followed the Phoenician thread. While I can understand the frustration of having a discussion blocked (however valid or invalid the reason) I think the method you are choosing to continue it is unprofessional. Grabbing email addresses from our public list is something which I'm sure scores of spammers do every day. In your desperate enthusiasm for your cause, you have reduced yourself to their level. You have not even limited yourself to those involved in the original Phoenecian thread which might have been slightly less unethical. The correct procedure would have been for you to announce on the Unicode list that you are starting a seperate list moderated by you and invite people to join it on a voluntary basis. I'm sure Rick McGowan and Sarasvati would have had no objection to such a posting. (I'm sure they will also allow this one!) Kevin Brown
Re: not font designers?
On Wed, 3 Nov 2004 at 10:32:39 -0800 (PST) Kenneth Whistler [EMAIL PROTECTED] wrote: As some have indicated, it is pretty clear that the number of people on the [EMAIL PROTECTED] discussion list who would self-identify as font designers is likely to be a rather small minority. Professional font designers hang out on *other* discussion lists. Since we're all outing ourselves here I have to declare that I *am* a font designer. I am on the unicode list (and I am also a member of the Unicode Consortium) because I love language and words and letters and because I believe that Unicode is one of the most important international cooperative projects this planet has ever seen. Kevin Brown
Script l (U+2113)
I've just noticed that the script l character (U+2113) is one of only two apparently mandatory characters (the other being estimated U+212E) included in addition to the MacOS Roman character set in a collection of recently released Linotype fonts. Is there any other common usage for U+2113 apart from as the liter/litre symbol that would explain its apparently mandatory inclusion in these fonts? Also, does this symbol usually occur in only one style/weight, namely italic regular? Or does it also appear in upright regular, upright bold, and italic bold depending on the typographic context? Kevin
Re: LATIN SMALL LIGATURE CT
Adam Twardoch [EMAIL PROTECTED] wrote: It doesn't matter whether a ligature is mandatory or not. Ligatures should not be encoded _at all_, and these encoded in the Alphabetic Presentation Forms are an uncomfortable compromise, and exception. I completely accept that the vast majority of ligatures can be decomposed into existing encoded characters without any loss of design integrity and therefore the case for encoding them is weak (and probably non-existent in the context of the new font technologies such as OpenType) But can someone explain to me why a ligatures such as ct which CANNOT be accurately decomposed into individual characters (at least, it can't if it's designed PROPERLY) shouldn't be encoded in its own right? Non-decomposability is the special feature of all the ligatures currently included in Alphabetic Presentation Forms. How about the German double s/eszett (U+017F) a ligature of long s and s which cannot be accurately built up from it's components. There was probably never any doubt that the eszett would be encoded since it appeared in codepages that predated Unicode but is the encoding of the eszett merely thought of as an uncomfortable compromise? There must be countless historical facsimile editions printed every year which use the st and ct ligature extensively. The production of these items would hugely benefit from having a fixed codepoint for ct instead of it wandering all over the PUA depending on what font you're using. I'd be happy if someone could point me to the exact Unicode 4 reference which deals with the issue of non-decomposable ligatures? Kevin
LATIN SMALL LIGATURE CT
This has possibly been canvassed before, but I was wondering why there is no character LATIN SMALL LIGATURE CT in Alphabetic Presentation Forms (or elsewhere)? The Alphabetic Presentation Forms range contains most of the other latin ligatures such as st, ff, fi, fl etc. I would have thought that the ct ligature was no more or less common than any of these. Adobe Pro fonts (eg Minion, Caslon, Garamond etc) include the ct ligature in the PUA. What is the history of the non-inclusion of the ct ligature in the Unicode Standard? Kevin
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: 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: Problem with Arial Unicode MS font for BOLD/ITALICS in PDF
Jain, Pankaj (MED, TCS) wrote: I am generating the PDF using XSLFO/FOP and Arial Unicode MS font for Global languages.And during Implementation I found that Bold/Italics character are not appearing in bold/Italic in PDF which was coming there is any Issue with Arial Unicode Font for Bold/Italic or I need to make some other configuration to fix it. Unlike the standard Arial family, Arial Unicode MS only comes with a single weight (regular) and style (roman). You can create synthetic (or faux) weights and styles using your application's style buttons and these will work perfectly well on screen and even with some printers (mainly inkjet). But these faux weights and styles will hardly ever work in desktop postscript printers, and never in pdfs or imagesetters. Kevin
Length of Unicode Name
Does the Unicode Standard specify an upper limit to the length of a character's Unicode Name? Kevin
I-Ching Hexagrams
I assume the 64 hexagrams in Unicode 4 (Beta) from U+4DCB-U+4DFF are indeed the hexagrams of the I-Ching? If so, I need to relate the proposed codepoints and names (eg 4DCBHEXAGRAM FOR STANDSTILL) to actual glyphs I already have in a font database. Is there a draft Code Chart illustrating the glyphs for these new additions? My problem would be solved if someone could confirm that the hexagrams in Unicode 4 (Beta) are listed in the same order as they appear in the I-Ching. Or maybe someone knows of a website where the hexagrams are illustrated along with their names. I've been looking but haven't found one yet. Thanks Kevin
Re: Impossible combinations?
On Sun, 2 Mar 2003, Kenneth Whistler wrote: Does anyone know of a Latin-based language in which it is possible to have a lowercase immediately followed by an uppercase in the SAME word? In addition to the examples pointed out by Roozbeh and Michael, this pattern is growing increasingly common in commercial English, where such forms as eBusiness and eSecurity are enjoying increasing vogue. And CamelCasing is apparent not only in technical terminology, but has spread to company names and the like, as well. Consider, e.g., PayPal. Thanks to everyone who responded. I must admit the last answer I expected to my question was English. At least I feel confident now that I won't be creating a major diplomatic incident if I don't cater for all possible lowercase-to-uppercase kerning pairs. I've already allowed for the McGowans and O'Reillys so I think I'll leave it at that. As to the many examples given of words (really two words without a space) such as PayPal, I've always called these Macintosh Words because I'm sure this practice was started many years ago by the people who wrote and named Mac applications, if not by Apple itself? Perhaps the philosophy here was that the space was just a waste of space, so to speak. On the other side of the fence are what I call Windows Words with not an uppercase in sight presumably first created by nerds with no time or inclination to use the Shift key eg filename.doc. I also give these the more poetic name eecummings words. The irony is that both Mac and Windows operating systems (written by those same nerds no doubt) are delightfully scornful of all this typographic preciousness on our part. If you have a file called PayPal and you try to create another file called PAYPAL or paypal or even PaYpAL both operating systems will put us firmly in our place with the response That name is already taken, please use a different name. Sigh. Kevin
Impossible combinations?
I'm working on a Latin-based font that's got a large number of kerning pairs already defined and I'm trying to pare this list of pairs down to the bare minimum. There seem to be many pairs which are unlikely ever to be used. These pairs all involve a lowercase on the left with an uppercase on the right. My intuition is to delete all such pairs but since I am not a linguist I thought I'd better check first. Does anyone know of a Latin-based language in which it is possible to have a lowercase immediately followed by an uppercase in the SAME word? Thanks, Kevin
Capital Letter H with line below
LATIN CAPITAL LETTER H WITH LINE BELOW does not appear to exist in Unicode 3.2, but the lowercase version is there (U+1E96). I have a map of Israel which has the transliterated names Hadera and Hefa typeset with a line below their first letter, CAPITAL H. On the same map, I have yet to find a place name that uses the LOWERCASE h with line below. Can anyone clear up this mystery? Kevin Brown
Discrepancy between Names List Code Charts?
This is my first posting to this list so please be gentle with me! I have come across a confusing discrepancy between the official unicode description of some characters (ie the description in the Names List) and the way they are graphically displayed in the Unicode Code Charts. This appears to have led to a lack of consistency between at least three ubiquitous unicode fonts - Lucida Unicode, Times New Roman (OT) and Arial MS Unicode. As an example, the following glyphs from Latin Extended-A is displayed in the Code Charts (online and in The Unicode Standard 3.0 book) with a comma below, but are described as follows in the current Names List: U+0136 LATIN CAPITAL LETTER K WITH CEDILLA U+0137 LATIN SMALL LETTER K WITH CEDILLA The current Adobe Glyph List names (in the last version issued v1.2 October 98) for these characters are Kcommaaccent and Kcommaaccent. These AGL names must have been been updated sometime between 1996 and 1998 because in the last version of Fontographer (v4.1.5, Oct 96) the character names were Kcedilla and kcedilla. (Likewise for L, l, N, n, G, g, R and r) For these characters, the Lucida Unicode font uses a cedilla, Times New Roman (OpenType version) uses a special modified cedilla/comma character, and Arial MS Unicode uses a comma. Compare this with the following characters: U+015E LATIN CAPITAL LETTER S WITH CEDILLA (AGL name: Scedilla) U+015F LATIN SMALL LETTER S WITH CEDILLA (AGL name scedilla) ...even though they have the same Unicode Names List description (ie WITH CEDILLA) as the K and k characters above, these characters are actually displayed with a cedilla in the Code Charts (ie not a comma as with the K and k etc). Furthermore, in the recently added Romanian Additions in Latin Extended-B, we find U+0218 LATIN CAPITAL LETTER S WITH COMMA BELOW (AGL name: Scommaaccent) U+0219 LATIN SMALL LETTER S WITH COMMA BELOW (AGL name scommaaccent) ...these WITH COMMA BELOW characters are displayed in the Code Charts with a comma - identically to the K, k, L, l, N, n, G, g, R and r characters described WITH CEDILLA You can see from the above examples that the Adobe Glyph List name (where it exists) is a more reliable indicator of of how the character is displayed in the Code Charts than the official description in the Unicode Names List. The trouble is there are only 1,050 characters in the AGL compared with over 50,000 currently described in Unicode! Can someone help me with this confusion as I am unsure how I should structure these WITH CEDILLA characters in fonts I'm working on. Am I just displaying my ignorance of European writing systems or does the Unicode Names List and/or the Code Charts need updating???!!! Kevin Brown
