[Printing-architecture] On the Continued Need for PostScript Workflows
msweet at apple.com
Thu Jun 20 13:29:44 UTC 2013
Please file a bug against the OpenPrinting filters:
When submitting a PostScript file to a PostScript printer, the preferred filter should be pstops. The PDF filters should only get involved for non-PostScript print jobs.
Can you update the OpenPrinting landing page to provide some common links near the top, including things like:
Downloading the current version
Right now everything is pretty buried and I can't even say whether the link I've provided above is correct for reporting bugs...
On 2013-06-19, at 6:49 PM, James Cloos <cloos at jhcloos.com> wrote:
>>>>>> "MS" == Michael Sweet <msweet at apple.com> writes:
> MS> For the "printing PS to a PS printer case", the existing CUPS pstops
> MS> filter should be the clear winner in cupsd's eyes - both the relative
> MS> cost and number of filters are lower than a pstopdf | pdftopdf |
> MS> pdftops route, and pstops isn't going anywhere.
> It, however, is not when one has the openprinting filters installed with
> cups 1.6. Then the *topdf filters and pdftopdf win out over everything else.
> For a test, I added a jetdirect service to my xinetd(8) and redirected
> jobs for a ps printer there (by removing the printer from the network
> and added its ip to the local box). The serice calls a script with
> cat(1)s whatever is sent to port 9100 to a file per accept(2).
> Printing a file which starts out:
> ,----[ head of: April-2007-July-To-Sam-Soap.ps ]
> | %!PS-Adobe-2.0
> | %%Creator: dvips(k) 5.95b Copyright 2005 Radical Eye Software
> | %%Pages: 1
> | %%PageOrder: Ascend
> | %%BoundingBox: 0 0 612 792
> | %%DocumentFonts: LucidaBright LucidaBright-Italic
> | %%DocumentPaperSizes: Letter
> | %%EndComments
> | %DVIPSWebPage: (www.radicaleye.com)
> | %DVIPSCommandLine: dvips -f
> | %DVIPSParameters: dpi=1200
> | %DVIPSSource: TeX output 2007.07.30:2101
> I end up with one which starts:
> ,----[ JD.6970 ]
> | %!PS-Adobe-3.0
> | %Produced by poppler pdftops version: 0.22.5 (http://poppler.freedesktop.org)
> | %%Creator: dvips(k) 5.95b Copyright 2005 Radical Eye Software
> | %%LanguageLevel: 2
> (It even gets the LanguageLevel wrong. The pdftops filter in cups-1.5
> knows to pass -level3 to poppler’s pdftops(1) for this printer, but the
> one in cups-filters refuses to. Hmmph.)
> As you can see, the filter must have been:
> pstopdf | pdftopdf | pdftops | pstops
> and not just pstops.
> Bebian bug#712237 notes that previous versions on deb had set the pstops
> cost in mime.conv to 65 rather than 66. Till’s reply notes that the 65
> was to avoid just this, but caused 1.6 to fail in «make test».
> Replicating that change (to 65) indeed does fix that issue here.
> MS> As for rasterization, generally people are using Ghostscript to
> MS> generate their raster data which supports both PDF and PostScript
> MS> input directly - no intermediate PDF there.
> But here, too, 1.6 with the openprinting filters forces everything
> through pdftopdf. This breaks my dymo and $30 mfd (which normally only
> gets used for scanning and mono copying, not printing; but even so...).
> I haven't re-tested those two this week (penny-pinching on that front :)
> but given what I found with the ps spool I expect those also to be
> unchanged from before. But perhaps lowering the pstops cost might help?
> MS> (On the Mac PS gets converted to PDF by Adobe's own PostScript
> MS> distiller, which Apple licenses, and then rasterized by
> MS> CoreGraphics' PDF engine...)
> How well does it handle device independent colour ps, such as:
> and the rgb vs cmyk test file:
> I'd be interested to see that pdf adobe generates from those.
> GS does a poor job with the first two, when converting to pdf.
> It does well with them when rendering to raster, at least when the
> destination colour-space is known/specified. But it ruins them when
> converting to pdf.
> JC>> Conversions can only cause damage.
> MS> Please leave the FUD at the door.
> Try running gs's ps2pdf on the CIELABsweep.ps above and then claim my
> comment were FUD.
> And remember that I specifically noted that I was speaking about Free
> Software. Adobe's distiller might get it right, but that does not help
> the rest of us.
> MS> We need to convert the input document into something the printer will
> MS> accept. If the printer accepts PostScript, we pass it through, adding
> MS> any printer options along the way with pstops.
> But not when the openprinting filters are used. At least not without
> changing the conversion costs, as per above.
> MS> If the printer needs PDF or raster data, we have to interpret the
> MS> PostScript file. In the case of "device independent color", that will
> MS> likely get converted to the printer's native color space (or the color
> MS> space it or the driver advertises for that purpose anyways), otherwise
> MS> you'll get some *really* strange looking output.
> I don't see any effort to tell gs to use a specific colour space when
> doing ps2pdf. And not all printer's native CMYK is known. Eg, my
> printer does its own management (speding some toner every time it powers
> up) so well that it makes no sense to spend cash on a specto. Instead,
> it it best to tag everything with a colour space. ps2pdf, however,
> forces everything to sRGB by default. And I don't see any effort to
> avoid that default.
>>> And it is not always even possible to convert jobs which use postscript
>>> as a language into equivilent PDF. The formats are just too different.
> MS> The core difference is that PostScript is a true programming language
> MS> with a (relatively) well-defined graphics language, while PDF is just
> MS> a (relatively) well-defined graphics language. PDF provides a
> MS> superset of the PostScript graphics language, and PDF color
> MS> management, imaging handling, and transparency support are far
> MS> superior to PostScript.
> Yes. I left that out as part of the attempt to keep the post short.
> MS> In any case, pstops is not going anywhere and is the preferred filter
> MS> for PostScript printing to a PostScript printer. If any distro has
> MS> changed that preference, please file a bug with the corresponding
> MS> distro.
> Gentoo does not change the default costs and gets hit by this bug when
> one installs 1.6 (which pulls in the openprinting filters packags).
> But I found today (thanks to that deb bug report I mentioned above) that
> up though 1.5 debian used to reduce the cost of pstops exactly to avoid
> my complaint, but stopped doing so and returned to the default costs
> with 1.6.
> From your notes, I take it that Apple's use of CUPS does the right thing
> on this front.
> It isn't a distribution bug, it is an openprinting filters bug.
> Hense my note here.
> James Cloos <cloos at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
Michael Sweet, Senior Printing System Engineer, PWG Chair
More information about the Printing-architecture