[Desktop_printing] Agenda proposal: Replace PostScript by PDF
as job transfer format
mike at easysw.com
Sat Jan 7 17:19:27 PST 2006
Hin-Tak Leung wrote:
> Kai-Uwe Behrmann wrote:
>> Some Xpdf cons:
>> - missing API/library
>> - no ICC colourmanagement / it is far away from Acroread
>> - missing 16-bit
> I may be wrong, but I believe I have come across some mention
> of (the commercial side of) xpdf being available as a windows DLL.
> So maybe API/library part of xpdf exists, but isn't open-source.
> - it is possibly similiar and more restrictive to ghostscript's AFPL
> situation - Maybe somebody on the list can investigate or elaborate?
Derek *does* provide a library to his commercial customers. The
open source code can be turned into one with some trivial changes,
as I've mentioned before.
>> GPL-GS8.50 shows better results than Xpdf3.01 for colour images.
> Yes, GPL 8.50 has just been released(?) (I saw it from cvs-commit
> feeds), so the difference between the GPL release with the AFPL release
> isn't that great - Ralph may like to eloborate? - But yes, the fact that
> 3rd party enhancements to GPL gs has to be re-done for each release is
> undesirable. On the whole, I feel a switch to pdf for merely
> annoyance with AFPL license is doing it for the wrong reason.
> (as I said, xpdf possibly has a commercial branch which is hidden
> away with the additional functionality that Kai-Uwe wants - so the
> situation is not exactly different with ghostscript on that front).
At this point, I'd like to suggest not talking about possible "secret
code" that has not been released with Xpdf. Instead, let's see if we
can get Derek (the author of Xpdf) in the loop to answer our questions.
I've already asked him if he can join in the discussions, and perhaps
even attend the printing summit.
> I would also like to raise one more issue (if not discussed before?):
> some general dicussion on speed and performance. I have some
> personal experience with xprint and it is very resource-hungry -
> e.g. try printing via mozilla a web page which would result in
> 30 physical A4 page of chinese - and I wonder if Cairo has a similiar
> problem; hpijs is very slow compared to pxlmono/pxlcolor, etc.
HPIJS is doing a lot more than the pxl drivers (HPIJS gets raster
data, pxl is vector...)
> On a related front, does any of the current invitees care about CJK
> printing? There are some unique technical issues with how best to
> process very large font sets in print jobs; and of course, also some
> internationalization, unicode, issues on the side as well.
I am interested in this, mainly only to the extent that allows CUPS
to more easily print CJK plain text files; the main stumbling block
is the lack of freely available Type 1 fonts that can be used with
any PostScript printer/interpreter.
Beyond that, we're already supporting localization and just need
translation work for the web interface and CUPS message catalogs...
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
More information about the Printing-summit