On Mon, 9 Dec 2002, Michael B. Allen wrote:
> Roland Mainz has released a new version of Xprint and appears to be > actively working on another. The mozilla website has some nifty looking > internationalized screenshots displaying Turkish, Chinese, etc. I've been > using an Xprint CUPS setup for sometime now with great success. > > http://xprint.mozdev.org/screenshots.html Yeah, Xprint works great (it can even be used to print out old Korean page with U+1100 Hangul Jamos) It solved a long-standing problem in X11(well, commercial Unix have some solutions for this), the enormous gap between what you see on the screen and what you get on paper(especially for non-European scripts). Because Xprint is an Xserver specialized for printing and shares many things with the main X server for screen rendering, what you see on the screen is faithfully replicated in what you print out with Xprint as long as two X servers(one for screen and Xprint) have access to the common set of fonts. However, the fact that Xprint is a specialized form of X*server* is also a weakness. You may know that the whole Linux (and FreeBSD and other Unix that rely on XFree86) community is moving away from the server side font and toward client-side font technology (fontconfig and Xft. http://fontconfig.org) With fontconfig and Xft, Unix/X11 finally got on par with Windows and MacOS in terms of font support. Arguably, this is the greatest development in X11 that happened in the last 10years. Mozilla-Xft is finally able to support CSS at the same level with Mozilla-Win and Mozilla-MacOS(no more need to tinker with XLFD and things like that). The problem of the server-side font becomes very obvious when you search for some Japanese(Chinese, Korean) words in Google (they don't have to be CJK, but to make sure that you get a truly multilingual page in UTF-8 that requires multiple fonts to render) and see Mozilla-X11core struggle (sometimes it can take almost 10 seconds at my PIII 750MHz with 384MB) to render the page. (Or, open up the font selection dialog box in Mozilla-X11core and compare that with the font selection dialog box in Mozilla-Xft/Mozilla-Windows/ Mozilla-MacOS. You can repeat the experiment with Mozilla-Xft.) Mozilla-Xft renders the page instantaneously. Also try to print the page with Xprint. Mozilla doesn't respond for as long as 30 seconds (depending on the complexity and the length of pages) until Xprint is done with searching for fonts to 'render' the page. Even with this weakness, Xprint is by far the best printing solution available at the moment for Mozilla under Unix/X11 because postscript printing module of Mozilla does not work very well yet(it works but is far behind what you can get with Mozilla-Windows and Mozilla-MacOS where the OS-level printing infrastructure is far superior to that under Unix/X11. Well, on some commerical Unix, it may be better.) It would be even greater if it's possible to combine Xprint somehow with fontconfig(although not likely). Better still is to write something like XftPrint(or XftPS) which would do to printing what Xft does to the screen rendering . There's an on-going project in Mozilla to directly use Freetype2 and embed type42 truetype fonts in PS output. This might be where fontconfig can come in to better support CSS in Mozilla printout as is done on the screen by fontconfig+Xft in Mozilla-Xft. > I hope the Linux distros jump on the bandwagon and start shipping > it along with an > Xprint enabled Mozilla (Red Hat's mozilla RPMs do not have Xprint enabled). I'm not sure why RH disabled Xprint in their Mozilla RPM. Xft, Xprint and PS printing module can coexist in Mozilla without much problem as far as I can tell. Perhaps, that blocking I mentioned above may not be acceptable? Jungshik Shin P.S. I'm CCing to fonts list of XF86. _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
