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
