[Printing-architecture] On the Continued Need for PostScript Workflows

Michael Sweet 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:

    Reporting Bugs
    Downloading the current version
    Mailing lists

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:
>  http://jhcloos.com/PostScript/CIELABsweep.ps
>  http://jhcloos.com/PostScript/XYZsweep.ps
> and the rgb vs cmyk test file:
>  http://jhcloos.com/PostScript/rgbcmyk.ps
> 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.
> -JimC
> -- 
> James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Michael Sweet, Senior Printing System Engineer, PWG Chair

More information about the Printing-architecture mailing list