JC> although I'm a little bit suprised at your enthusiasm for the thing.
JS> I'm not so enthusiastic about it as you may think.
Sorry for mis-reading your mail, then. (For my defence, I did state
my surprise.)
JS> Nonetheless, [Xprint] works _now_.
Point taken.
JS> As for complex script rendering, it's possible...
You'll doubtless agree with me that what you're describing are a
workarounds for the intrinsic limitations of Xprint -- more usually
known as hacks. Cunning schemes such as that have existed under X11
for decades now -- it's high time to move on.
JC> There is also no way[1] how Xprint could implement dynamically
JC> generated fonts, as required for example by CSS2.
JS> I'm a bit confused as to what you meant by 'dynamically generated
JS> fonts'.
Fonts that are not permanently installed in the system, but are
dynamically generated by the application from e.g. data downloaded
through HTTP (as with ``web fonts''), data embedded within data
structures (as with PDF) or even dynamically computed data.
So yes, we did think of the same thing.
JC> incrememtal uploading of fonts to the printer at the PS level
JS> provided that the font resolution mechanism is tied with fontconfig
Goes without saying.
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).
PostScript supports a dozen or so font formats, but the only ones that
are supported on all implementations are Type 1 and Type 3 fonts (not
CIDFonts). I think that nowadays Type 1 and Type 3 CIDFonts can be
taken for granted.
There are at least four ways of dealing with TTFs in PS. Type 42
CIDFonts is the most efficient, and should most definitely be used by
folks with new printers. Type 42 fonts (not CIDFonts) are supported
since version 2017 and are barely slower than Type 42 CIDFonts.
Conversion to Type 1 fonts works everywhere, gives excellent results,
and the code is readily available (ttftpt1). Finally, if everything
else fails, you can always download a Type 3 bitmap version; this
should only happen at the user's explicit request.
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.
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.
JS> Well, that's not so bad as you think. What percentage of
JS> average Linux(or other free Unix) users do you think own a
JS> postscript printer?
I don't know, and I don't care. I'm opposed to the private ownership
of the means of production.
Seriously, though: where I live, most people don't own a printer at
all. For printing, they take a floppy to their place of work or
study, or carry it to the closest print shop. As people don't usually
know what kind of printer they will end up printing on, portable
PostScript is needed.
JS> How about something like XftPS on 'the client side'?
Absolutely. It's a mere matter of hacking.
Juliusz
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
