On 11 Dec 2002, Juliusz Chroboczek wrote: > Sorry for mis-reading your mail, then.
No problem :-) > JS> As for complex script rendering, it's possible... > You'll doubtless agree with me that what you're describing are a ... > for decades now -- it's high time to move on. Yes, I agree with you, but somebody needs to do the work. Actually, the most difficult part may not be programming but may be getting/making some intelligent fonts (opentype or AAT) for complex scripts. For Indic scripts, things are going pretty well and the number of freely available opentype fonts for Indic scripts are increasing. For Korean, it's not so good as I wrote before. I have yet to see a single free opentype font. BTW, you'll be surprised to read comments made by some people at <http://bugzilla.mozilla.org/show_bug.cgi?id=144663>. They want to kill PS module in mozilla in favor of Xprint. > JC> I'm a little bit suspicious about their choice to use Type 42 CIDFonts > JS> Given that truetype fonts are much easier to come by than genuine > JS> CID-keyed fonts for CJK (which is also true of truetype fonts vs PS > JS> type 1 fonts for European scripts although to a lesser degree), I guess > JS> the choice is all but inevitable... > > I may have misunderstood something, but last time I checked the > approach was to use Type 42 CIDFonts *only*. These are currently a > fairly rare beast (only supported since version 3012, if memory serves). I also thought that's the case. However, Brian Stell changed the plan (see http://bugzilla.mozilla.org/show_bug.cgi?id=144663. ) and he's now gonna use type 8 (neither type 11=what you're calling type42 CIDFont = CIDFont type2 nor type 42). What's type 8 font, btw? > JC> [using Type 42 CIDFonts] will require many users to rasterise > JC> everything with ghostscript on the host, with all the ensuing > JC> performance and printing quality issues. Because you wrote the above, I thought that you had reservation about doing everything on the host side regarding printers as dumb devices which may sacrifice the printing quaility. I also thought that you prefer to leave as much as possible for PS printers to take care of. That's why I didn't even mention the most certain way to produce portable PS output (type3 bitmap) and I wrote about the percentage of end-users owning PS printers. > Conversion to Type 1 fonts works everywhere, gives excellent results, > and the code is readily available (ttftpt1). Finally, if everything Does this conversion code also work for large CJK ttf fonts(with more than 256 glyphs)? Or, does it also support conversion to composite font(OCF?)? > As you see, I am not arguing against support for CIDFonts; I'm merely > stating that making Type 42 CIDFonts the only download format for TTFs > makes me er... suspicious. I'm not against producing portable PS, either :-). However, I think the portability of PS output doesn't matter much considering the way printing is handled these days in Unix/Linux. Jungshik -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/