On 10 Dec 2002, Juliusz Chroboczek wrote: JS> Even with this weakness, Xprint is by far the best printing JS> solution available at the moment for Mozilla under Unix/X11 JS> because postscript printing module of Mozilla does not work very JS> well yet
JC> Xprint might work for CJK fonts, It does work for CJK now. Especially version 0.8 of Xprint with truetype font support works pretty well. Even the PS output produced by 0.7 with X11 bitmap fonts doesn't look that bad. JC> although I'm a little bit suprised at your enthusiasm for the thing. I'm not so enthusiastic about it as you may think. A better word to characterize what I think about it is ambiguity. See my postings to mozilla-i18n newsgroup <news://news.mozilla.org/netscape.public.mozilla.i18n>. When I wrote 'by far the best', I meant _as of now_ it gives the best match between the print out and the screen rendering. For CJK web pages, Mozilla PS module can't do that because only *one* PS font for each language can be specified. That is, on the screen, Mozilla(especially Mozilla-Xft) can be a good implementation of CSS, but on the print out, it cannot. Xprint is not perfect, but it's better than printing out everything(CJK and non-Western European) in a single font (specified in pref. file which has to be hand-edited by end-users.). Besides, complex script cannot be printed out at all by Mozilla under Unix without Xprint. With Xprint, it's possible to print out web pages in complex scripts provided that you can render them on the screen with Mozilla-X11core. That's a big difference. JC> There is no way, though, how Xprint JC> could work for complex scripts without standardising on glyph JC> mappings. As I understand it, Xprint is a specialized form of X11 server combined with some X clients. Therefore, I think it has all sorts of weakness found in server-side font model we have been moving away from. It's not fast and nor efficient (compared with client-side font technology) and it doesn't support 'modern' CSS-based font selection/resolution at the same level as provided by fontconfig. Nonetheless, it works _now_. As for complex script rendering, it's possible to print them out as I wrote above and my test with Old Korean showed. (see http://bugzilla.mozilla.org/show_bug.cgi?id=176315). Standardizing on glyph mapping is not a requirement if we just deal with a single application program(e.g. Mozilla). Mozilla-X11 has a way to map the last two fields of XLFD to a mapping between a string of Unicode characters and a sequence of glyphs. That's what Mozilla-X11 uses to render Indic scripts, Thai and Hangul Conjoining Jamos. (Mozilla doesn't yet support opentype fonts at least under X11. Some Pango code was borrowed but that's not from pango-xft but from pango-x). Because Xprint module of Mozilla shares many things with Mozilla-X11corefont/Mozilla-Gtk, without doing anything, Xprint just works when it comes to printing out web pages in Indic scripts, Thai and Old Korean. Of course, I'm well aware that we have to use opentype fonts with gsub/gpos tables for complex script rendering. However, we also need a short-term solution that works now. For instance, there is not a single opentype font freely available for old Korean. The situation is much worse than that for Indic scripts for which free opentype fonts began to emerge. In the meantime, we have to resort to font-specific-encoding hacks. JC> There is also no way[1] how Xprint could implement JC> dynamically generated fonts, as required for example by CSS2. I'm a bit confused as to what you meant by 'dynamically generated fonts'. Did you mean 'web fonts'? Can you tell me what you meant? JC> The right approach is obviously to do incrememtal uploading of fonts JC> to the printer at the PS level, as the Mozilla folks are trying to do. I totally agree with you provided that the font resolution mechanism is tied with fontconfig. JC> I'm a little bit suspicious about their choice to use Type 42 CIDFonts Given that truetype fonts are much easier to come by than genuine CID-keyed fonts for CJK (which is also true of truetype fonts vs PS type 1 fonts for European scripts although to a lesser degree), I guess the choice is all but inevitable(perhaps OpenOffice also adopted this approach). Do you have a better idea? Judging from your reservation about the rasterization on the host side, what you're thinking of cannot be converting all the glyphs into bitmap and putting them in the PS output. Anyway, I believe this 'mini-project' for Mozilla printing has be 'glued' with fontconfig in CSS2 font resolution so that the screen rendering and PS output use the same set of fonts. What I can think of as an alternative to embedding type 42 PS font(type 2 CIDFont) is just to refer to CID-keyed fonts/type 1 fonts in the PS output and let a real PS printer or ghostscript do the rest of the job. This is similar to what the present PS module for Mozilla does. However, in order to get a faithful replica of the screen rendering, fonts available to Mozilla and fonts available to ghostscript or PS printers (either downloadable or printer-resident) have to be closely matched. That may be easy for European scripts (for which fonts availability is much more uniform across different 'media/platforms' than for non-European scripts), but that's not so easy for non-European scripts. JC> for that, though, as it will require many users to rasterise every- JC> thing with ghostscript on the host, with all the ensuing performance JC> and printing quality issues. Well, that's not so bad as you think. What percentage of average Linux(or other free Unix) users do you think own a postscript printer? Many people at work and school have access to PS printers. However, most people at home don't have a PS printer. Most of them have PCL4/5/6 printers(I don't know the situation in Europe, but in East Asia and North America, PS printers are way more expensive than PCL 5/6 printers.) Therefore, they have to filter their printer jobs through ghostscript in any case. Especially for CK users, printer-resident CID-keyed fonts are almost non-existent (even if they own PS printers) while CJK truetype fonts are relatively easy to get. In addition, modern printing subsystems being actively developed for Unix such as CUPS (http://www.cups.org and http://www.linuxprinting.org) make it very easy to use ghostscript as a transparent printing filter. JC> [1] Without a major protocol extension. Way, way more complex than JC> what Xft does -- basically you'd have to duplicate the most complex JC> part of PS, the font interfaces, at the X11 protocol level. How about something like XftPS on 'the client side'? I guess the extensive X11 protocol level change is required because Xprint is server based. What I have in mind is a library for PS generation that shares font-resolution mechansim(fontconfig) with Xft and that is as easy as Xft to use. Perhaps, I have to drop 'X' in 'XftPS' because it's little to do with X. Jungshik _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
