Re: [Fonts]Re: Xprint
I think we've strayed from the initial subject. I've got no objection to Mozilla using Type 42 CIDFonts, Type 100 halftones, Type 4 images and an embedded APL interpreter. Whatever. As long as they don't use Xprint. JC their choice to use Type 42 CIDFonts JS Given that truetype fonts are much easier to come by than genuine JS CID-keyed fonts It's funny how we come to opposite conclusions from the very same facts. Because TTFs are plenty, one needs to support them well on all printers. Thus, one should not require the support for Type 42 CIDFonts. But I really have no problem with that. Font format conversion can always be added at a later stage. JS I also thought that's the case. However, Brian Stell changed the JS plan (see http://bugzilla.mozilla.org/show_bug.cgi?id=144663. ) JS and he's now gonna use type 8 (neither type 11=what you're calling JS type42 CIDFont = CIDFont type2 nor type 42). Yes, the terminology is confusing. To be pedantic, I was speaking of serialised CIDFont resources with a CIDFontType of 2 and a FontType of 11, which happens to contain Type 42 charstrings. JS What's type 8 font, btw? No idea. I can't find them either in either PLRM 3 or the 3012 supplement. Are you sure you're not thinking of Type 0 fonts (composite fonts) with a FMapType of 8, which is what Adobe used in the Japanese market before they came up with CIDFonts? These will work on all level 2 devices (possibly requiring that a proprietary Adobe procset be downloaded) and on Japanese level 1 devices. In my humble opinion, Type 0 fonts are a hack for doing in the PS interpreter something that really ought to be done in the host (font switching). But then, Mozilla is written in C++, and it may be simpler to implement font switching in PostScript ;-) JS I also thought that you prefer to leave as much as possible for PS JS printers to take care of. There's a compromise to make between how much information you want to give the PS interpreter and how portable you want to be. I think that using Type 42 CIDFonts (whatever you may think of my terminology) with an option to use Type 1 base fonts is the sweet spot. Conversion to Type 1 fonts works everywhere, gives excellent results, and the code is readily available (ttftpt1). JSDoes this conversion code also work for large CJK ttf fonts(with more JS than 256 glyphs)? Or, does it also support conversion to composite JS font(OCF?)? Yes. Yes. Although with very large fonts you may run out of memory on very old PS devices if you're not careful. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Xprint
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 Xprint might work for CJK fonts, although I'm a little bit suprised at your enthusiasm for the thing. There is no way, though, how Xprint could work for complex scripts without standardising on glyph mappings. There is also no way[1] how Xprint could implement dynamically generated fonts, as required for example by CSS2. The right approach is obviously to do incrememtal uploading of fonts to the printer at the PS level, as the Mozilla folks are trying to do. I'm a little bit suspicious about their choice to use Type 42 CIDFonts for that, though, as it will require many users to rasterise every- thing with ghostscript on the host, with all the ensuing performance and printing quality issues. Juliusz [1] Without a major protocol extension. Way, way more complex than what Xft does -- basically you'd have to duplicate the most complex part of PS, the font interfaces, at the X11 protocol level. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Xprint
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
[Fonts]Re: Xprint
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
