Re: Big question: CJK font support in systems and applications
Dear Ken, thank you for your reply. This sheds some light onto what I've discovered so far. Especially the information that CID font 0 won't work on Windows NT/2000! This was actually unclear to me. Can you please confirm which latest Windows ATM versions for which Windows systems do support these fonts? Does ATM 4.0 or 4.1 for Windows 98/ME support flat CID fonts? I am very well aware that books such as yours do age when it comes to the particular versions of software etc. So again, thank you for the update. These work on Mac OS using ATM. Mac OS X should handle them without ATM (the ATM rasterizer is built-in). We call these naked-CID fonts. This is because the CIDFont file is a flat binary file, not encapsulated into a font suitcase. But I understand that there is a suitcase plus that flat file -- just like with regular Mac Type 1 fonts. Is that correct? These work on Mac OS using ATM, in much the same way as #2 above. We call these sfnt-CID fonts. Are there any vendors who specifically make sfnt-CID rather than flat CID? Does Adobe make sfnt-CID fonts? When you write cmap 3.1 Unicode encoding, do you mean access to the Supplementary Planes? No, in fact, I meant the platform id for which a given encoding is written. As you know, a cmap table of a TrueType font or OpenType font can contain multiple encodings. Each platform is supposed to use one of these encodings. Currently, 1.0 (Macintosh) and 3.1 (Windows/Unicode) platform-dentoed encodings are mostly used. MacOS used the encodings denoted as 1.0 in the sfnt fonts, but currently, my understanding is that the 3.1 encoding entries are used when MacOS reads flat TTF or OTF files. You also asked about Arabic/Indic text, and I can say that those scripts are beyond the scope of my book. I am sorry, but you need to look elsewhere. That was, indeed, just an extending question. I'm aware that Arabic and Indic involve very different issues when processing text, and that the major obstacle for these languages is not about large character sets, but rather about complex composition rules. I was just curious if there are any parallels, that is, for example -- if a given font format is used for a given system to process CJK text, that would mean it also is used for Arabic/Indic -- or not. Thank you for the response, Adam
Re: Opentype support under Liunx
What exactly do you need? With FreeType 1.x comes support for OpenType GSUB and GPOS tables (recently updated to cover OpenType version 1.3): I'm studying ways to provide Linux with unicode-compliant Myanmar character fonts. Mark Leisure use .bdf format to enable to enter unicode values easily for some Indic fonts. With reference to that, I did .bdf !!! Now, my MS Windows platform friends are doing Open Type. Then, I became to think that it would be nice that we use the same format regardless of the platform and there I'm stuck:( Btw, am I digging the right thing? Sould I just stick with .bdf at the moment But, Unicoders' preferences and responses are so invaluable to me and so informative that I'm moved a bit. ftp://ftp.freetype.org/pub/unstable/freetype-current.tar.gz I have both FT1.3 and 2.0 as the latest. I have to give myself some more time working around with those. IIRC, the Pango complex script layout library uses this (ported to FreeType 2.x), so it is possible to make applications on Linux and similar platforms OpenType-aware. I don't know whether Pango already has a module for Burmese -- I'm quite sure that the author of Pango would be happy if you can contribute something :-) Yes. Pango has done something about Myanmar (Burmese as you quote). And the author also contacted me (actually to Myanmar Linux User Club under Yahoo) to test for him. Unfortunately, I was not serious about this at that time and got lost of his contact after a couple of correspondences. As for now, I'm more than serious and It is time I should contact him again to merge our activities. Thank you for your concern and your info. Regards, William [EMAIL PROTECTED] P.S. Oh !!! In case I produce anything, it will be GPL'ed.
Re: Opentype support under Liunx
At 04:26 PM 8/17/01 -0700, Brian Stell wrote: There are various uses of TrueType and its feature in Linux systems. To my knowledge no Linux app currently uses all the OpenType features; eg: the GPOS table. Thanks for the info. (of course motivated individuals could go to google and search for truetype linux and opentype linux) Internet (Web) stuff in Myanmar is not very handy and not publicly available yet. Had it not been the case, I'd have googled happily and lengthily. However, when I'm privileged to use it sometimes, I will do that. But bandwidth...on-line time..are limited.:( If you JUST WANT TO USE TRUETYPE FONTS you probably want to set up a X font server. X font servers make the new fonts appear to older apps just like one of the older fonts. This URL is a bit out of date but it should give you a hint: http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/ GOT it. Note however, not all older apps interact perfectly with the new fonts. If you are WRITING X CODE, want to use an Xlib like API, you can use Xft library to access FreeType2: http://www.xfree86.org/~keithp/render/ Not that advanced yet. If you are WRITING CODE and do not mind learning a new API you could directly access FreeType2: http://www.freetype.org/ Note: the learning curve for the FreeType API is a bit steep but if you really want a lot of information from the font ... I'm currently dealing with freetype and pango. Thank you all for your concern and continued support. Regards, william
Re: Transcriptions of Unicode
I happened upon a passage bolstering Mario's point that the English pronunciation of long U (as yoo, /ju/) does derive from it's being the closest pronunciation that the English could make to the French pronunciation of U (as /y/). That passage is in Honni soit qui mal y pense : L'incroyable histoire de l'amour entre le français et l'anglais. It is on page 158, in Pourquoi dit-on « miouzik » en anglais ? (I recommend the book: the writing is clear and accessible even for someone (like me) of limited French.) I put a link to the book on my booklist (http://www.macchiato.com/books/nonfiction.html). Mark — Ὀλίγοι ἔμφονες πολλῶν ἀφρόνων φοβερώτεροι — Πλάτωνος [http://www.macchiato.com] - Original Message - From: Marco Cimarosti [EMAIL PROTECTED] To: Unicode List [EMAIL PROTECTED] Sent: Monday, January 15, 2001 01:15 Subject: RE: Transcriptions of Unicode Mark Davis wrote: Much as I admire and appreciate the French language (second only to Italian), the proximate derivation of Unicode was not from that language, and the transcription should not match the French pronunciation. Instead, it has solid Northern Californian roots (even though not exactly dating from the Gold Rush days). Of course, my comment about French pronunciation was only partially serious -- I should have added as smiley. But I think that /ynikod/ is the actual pronunciation of Unicode in French (as opposed to most other European language, that simply approximate the English pronunciation). So, as you explained that you are listing languages, and that you accept more than one language for each script, you might consider a second IPA example. According to the references I have, the prefix uni is directly from Latin while the word code is through French. I wonder what directly from Latin may mean in the case of English. Because of some timing problems, I would say it means: through direct knowledge of *written* Latin. A direct derivation from Latin of English uni- would imply that, at some age, English scholars used to read Latin with a pronunciation influenced by French. In fact, the initial [ju:] is the regular English approximation of French vowel [y]. (Is this likely?) The Indo-European would have been *oi-no-kau-do (give one strike): *kau apparently being related to [...] caudal, [...] Wow! So Unicode also means single tail, after all... What would that be in Chinese? :-) Marco
Re: Opentype support under Liunx
I'm studying ways to provide Linux with unicode-compliant Myanmar character fonts. Mark Leisure use .bdf format to enable to enter unicode values easily for some Indic fonts. With reference to that, I did .bdf !!! How did you do it? With two preprocessors? The first reorders the input characters, the second maps the reordered characters to composite glyphs? Now, my MS Windows platform friends are doing Open Type. Then, I became to think that it would be nice that we use the same format regardless of the platform and there I'm stuck:( If the font works with Windows, it works with Linux also (using FreeType). The only thing needed is the reordering preprocessor. Btw, am I digging the right thing? Sould I just stick with .bdf at the moment It depends. For a terminal, BDF is optimal. For printing, you need outline fonts. Werner
Re: Opentype support under Liunx
Thank you for your explanation. Unix needs some bdf fonts if you want to use X terminal emulators (e.g. xterm). Unix has much better support for bitmapped fonts than Windows does, now doubtless about it. Thanx. and there's also no working scaled font editors for Unix (that I've ever heard of) Do things under Windows and then port to *nixes:) That is what i do and even for the .bdf's. , so it's not surprising that Unix people would do bdf. TrueType/OpenType fonts are also less supported than BDF. OTOH, OpenType can produce _much_ better output, especially when printed (if you can find a program that can print a OpenType font under Linux.) Yeahhh I've been with .bdf since I started doing font business under linux. Whether or not you should switch to OpenType is up to you. I just wanna shed the light to the dark side of it. Just checking ways around. I've not decided yet to switch as I need to study more about it. One thing for granted, i'd never leave my .bdf thing. OpenType fonts take a lot more time to make than BDF, and most TrueType/OpenType font editors are several hundred dollars and for Windows or Macintosh. MS's VOLT and Adobe's OFD** can be obtained by licensing freely after a number of questions It also takes a lot more artistic ability to do a good scaled font instead of a small bitmapped font. Noted. regards, [EMAIL PROTECTED] http://www.MyanmarLUG.org
