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

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

[James Cloos]

I've been trying for months to write a whitepaper on this subject, but
haven't been comfortable with the tone I end up with.  This is getting
more important, though.  So I'll try to be succinct, even if that might
come off as blunt.  Apologies in advance for feather ruffling.

*Any* conversion of PostScript into PDF in the print work flow -- ie, in
the cups filters -- is broken and unacceptable.

PostScript files exist; they do not magically disappear just because PDF
is available.

PostScript printers are still more common than PDF printers.  And they
have *long* lifetimes.  (In the US, printers have a five-year depreci-
ation schedule and one can expect a much longer service life.)

When printing an existing ps file -- including when printing from
programs which can generate ps but not pdf -- the postscript MUST be
modified only by pstops when sending on to a ps printer, or MUST be
rendered directly to a raster format when printing to printers which
require raster input.

Conversions can only cause damage.

Artifex refuses to ensure that gs' pdfwriter generates device indepen-
dent colour when given a source file with device independent colour
(evidently it is a large job for which they do not have a paying
customer).  Cf the relevant WONTFIXes.

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.

It is perfectly OK -- even welcome -- to prefer PDF when the original
file is not already in a page description format or language.

But the only molestation a postscript file should endure is that
specified by the ppd and user-selected options.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

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

[Ira McDonald]

[-- Attachment #1: Type: text/plain, Size: 3333 bytes --]

Hi James,

I sympathize with your concerns, but...

(1) PostScript filters aren't going to be maintained in CUPS in the future
(as far as I know)

(2) PWG IPP Everywhere (the only open standard mobile printing protocol)
abandons PostScript entirely and requires PDF

(3) Of the recent printers that I'm aware of, more are supporting native PDF
than native PostScript

(4) PostScript is deservedly disliked by government standards agencies
around the world because of how easily it can be exploited for security
attacks

I agree that PostScript files won't go away, but they are being increasingly
converted at the *source* content provider to PDF for interoperability.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Mon, Jun 17, 2013 at 8:14 PM, James Cloos <cloos@jhcloos.com> wrote:

> I've been trying for months to write a whitepaper on this subject, but
> haven't been comfortable with the tone I end up with.  This is getting
> more important, though.  So I'll try to be succinct, even if that might
> come off as blunt.  Apologies in advance for feather ruffling.
>
> *Any* conversion of PostScript into PDF in the print work flow -- ie, in
> the cups filters -- is broken and unacceptable.
>
> PostScript files exist; they do not magically disappear just because PDF
> is available.
>
> PostScript printers are still more common than PDF printers.  And they
> have *long* lifetimes.  (In the US, printers have a five-year depreci-
> ation schedule and one can expect a much longer service life.)
>
> When printing an existing ps file -- including when printing from
> programs which can generate ps but not pdf -- the postscript MUST be
> modified only by pstops when sending on to a ps printer, or MUST be
> rendered directly to a raster format when printing to printers which
> require raster input.
>
> Conversions can only cause damage.
>
> Artifex refuses to ensure that gs' pdfwriter generates device indepen-
> dent colour when given a source file with device independent colour
> (evidently it is a large job for which they do not have a paying
> customer).  Cf the relevant WONTFIXes.
>
> 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.
>
> It is perfectly OK -- even welcome -- to prefer PDF when the original
> file is not already in a page description format or language.
>
> But the only molestation a postscript file should endure is that
> specified by the ppd and user-selected options.
>
> -JimC
> --
> James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>

[-- Attachment #2: Type: text/html, Size: 4763 bytes --]

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

[James Cloos]

>>>>> "IM" == Ira McDonald <blueroofmusic@gmail.com> writes:

IM> (1) PostScript filters aren't going to be maintained in CUPS in the future
IM> (as far as I know)

When I asked Michael whether cups would continue to include the pstops
filter, he replied that it would.

IM> (2) PWG IPP Everywhere (the only open standard mobile printing
IM> protocol) abandons PostScript entirely and requires PDF

IPP everywhere printers will take years to replace the existing ps
printers, as I noted.  Maybe ten to twenty years from now the existing
(and about-to-be-deployed) ps printers will be gone.

IM> (3) Of the recent printers that I'm aware of, more are supporting
IM> native PDF than native PostScript

Not according to the ad copy I have read.

IM> (4) PostScript is deservedly disliked by government standards agencies
IM> around the world because of how easily it can be exploited for security
IM> attacks

Nonetheless, if the printer is ps the job has to be submitted as ps.

IM> I agree that PostScript files won't go away, but they are being increasingly
IM> converted at the *source* content provider to PDF for interoperability.

And when they are converted at the source, that is fine.

I tried to be specific that it is *in the cups filters* that ps never
should be converted into pdf.

Don't get me wrong.  I *love* ipp-everywhere.  But the existing printers
do not go away overnight.  And many seem to last forever.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

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

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

Ira,

On 2013-06-17, at 8:45 PM, Ira McDonald <blueroofmusic@gmail.com> wrote:
> Hi James,
> 
> I sympathize with your concerns, but...
> 
> (1) PostScript filters aren't going to be maintained in CUPS in the future
> (as far as I know)

This isn't exactly correct.

The CUPS PPD APIs were deprecated in CUPS 1.6 in favor of new APIs based on IPP Everywhere that better abstract the implementation details of printers and drivers in the system.  In fact, the current implementation is (internally) based on PPDs, as that is how CUPS does printer drivers.

The goal is to eliminate dependence on PPD files, not to eliminate PostScript printing specifically, because PPDs are (and always were) a limiting factor in supporting printer features in CUPS.  The last update to the PPD spec was in 1996 - printers (and how they are used) have changed a LOT since then...

Once applications and drivers no longer depend on the CUPS PPD API, we can work to separate the PPD API and PostScript printer support so that it can be maintained in parallel to any non-PS support.

> (2) PWG IPP Everywhere (the only open standard mobile printing protocol)
> abandons PostScript entirely and requires PDF

Just to be clear: IPP Everywhere does not forbid PostScript, and in fact is completely silent on support for it.  I suspect that future IPP Everywhere printers may offer PostScript support as part of the "legacy" language support for older OS's.

> (3) Of the recent printers that I'm aware of, more are supporting native PDF
> than native PostScript

My view of the products coming out does show some new products that are PDF-only vs. PDF + PostScript.  The combo products typically use a RIP (internal or external) that supports both with a common rendering backend, usually with an intermediate display list representation (for banding).

Most printers are still raster-only, but there are some new printers in the sub-$250 price point that are offering PDF support now...

> (4) PostScript is deservedly disliked by government standards agencies 
> around the world because of how easily it can be exploited for security
> attacks

In the realm of security, PDF has its share of issues as well.  I avoid slinging the security arrow because of that...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


[-- Attachment #2: Type: text/html, Size: 4687 bytes --]

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

[Michael Sweet]

James,

On 2013-06-17, at 8:14 PM, James Cloos <cloos@jhcloos.com> wrote:
> ...
> PostScript files exist; they do not magically disappear just because PDF
> is available.

Agreed, however PostScript is increasingly in the minority.

> PostScript printers are still more common than PDF printers.

Most PostScript printers also support PDF these days.  In fact, this year saw the introduction of some printers that support PDF but *not* PostScript.  And of course MOST printers sold in the last 20 years have had neither PostScript nor PDF support...

> ...
> When printing an existing ps file -- including when printing from
> programs which can generate ps but not pdf -- the postscript MUST be
> modified only by pstops when sending on to a ps printer, or MUST be
> rendered directly to a raster format when printing to printers which
> require raster input.

For the "printing PS to a PS printer case", the existing CUPS pstops filter should be the clear winner in cupsd's eyes - both the relative cost and number of filters are lower than a pstopdf | pdftopdf | pdftops route, and pstops isn't going anywhere.

As for rasterization, generally people are using Ghostscript to generate their raster data which supports both PDF and PostScript input directly - no intermediate PDF there. (On the Mac PS gets converted to PDF by Adobe's own PostScript distiller, which Apple licenses, and then rasterized by CoreGraphics' PDF engine...)

> Conversions can only cause damage.

Please leave the FUD at the door.

> Artifex refuses to ensure that gs' pdfwriter generates device indepen-
> dent colour when given a source file with device independent colour
> (evidently it is a large job for which they do not have a paying
> customer).  Cf the relevant WONTFIXes.

We need to convert the input document into something the printer will accept.  If the printer accepts PostScript, we pass it through, adding any printer options along the way with pstops.

If the printer needs PDF or raster data, we have to interpret the PostScript file. In the case of "device independent color", that will likely get converted to the printer's native color space (or the color space it or the driver advertises for that purpose anyways), otherwise you'll get some *really* strange looking output.

> 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.

The core difference is that PostScript is a true programming language with a (relatively) well-defined graphics language, while PDF is just a (relatively) well-defined graphics language.  PDF provides a superset of the PostScript graphics language, and PDF color management, imaging handling, and transparency support are far superior to PostScript.

In any case, pstops is not going anywhere and is the preferred filter for PostScript printing to a PostScript printer.  If any distro has changed that preference, please file a bug with the corresponding distro.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[James Cloos]

>>>>> "MS" == Michael Sweet <msweet@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@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

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

[Michael Sweet]

James,

Please file a bug against the OpenPrinting filters:

    https://bugs.launchpad.net/ubuntu/+source/cups-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.


Till,

Can you update the OpenPrinting landing page to provide some common links near the top, including things like:

    Reporting Bugs
    Downloading the current version
    Documentation
    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@jhcloos.com> wrote:

>>>>>> "MS" == Michael Sweet <msweet@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@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[James Cloos]

>>>>> "MS" == Michael Sweet <msweet@apple.com> writes:

MS> Please file a bug against the OpenPrinting filters:

MS>     https://bugs.launchpad.net/ubuntu/+source/cups-filters

MS> When submitting a PostScript file to a PostScript printer, the
MS> preferred filter should be pstops.  The PDF filters should only get
MS> involved for non-PostScript print jobs.

https://bugs.linuxfoundation.org/show_bug.cgi?id=1138

(When I went looking through tabs to find the bug id number, I found
that I hadn’t hit Submit – or hadn’t pressed the button hard enough.
So it is dated Sunday instead of Friday....)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

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

[Till Kamppeter]

On 06/20/2013 03:29 PM, Michael Sweet wrote:
> James,
> 
> Please file a bug against the OpenPrinting filters:
> 
>     https://bugs.launchpad.net/ubuntu/+source/cups-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.
>

James has filed it as

https://bugs.linuxfoundation.org/show_bug.cgi?id=1138

and I have fixed it now in the BZR repo. Will be included in
cups-filters 1.0.35.

> 
> Till,
> 
> Can you update the OpenPrinting landing page to provide some common links near the top, including things like:
> 
>     Reporting Bugs
>     Downloading the current version
>     Documentation
>     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...
> 

Done:

https://www.linuxfoundation.org/collaborate/workgroups/openprinting/cups-filters

and linked from appropriate places on the front page

http://www.openprinting.org/

   Till

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

[Michael Sweet]

Till,

Great news all around, thank you!


On 2013-06-25, at 6:05 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:

> On 06/20/2013 03:29 PM, Michael Sweet wrote:
>> James,
>> 
>> Please file a bug against the OpenPrinting filters:
>> 
>>    https://bugs.launchpad.net/ubuntu/+source/cups-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.
>> 
> 
> James has filed it as
> 
> https://bugs.linuxfoundation.org/show_bug.cgi?id=1138
> 
> and I have fixed it now in the BZR repo. Will be included in
> cups-filters 1.0.35.
> 
>> 
>> Till,
>> 
>> Can you update the OpenPrinting landing page to provide some common links near the top, including things like:
>> 
>>    Reporting Bugs
>>    Downloading the current version
>>    Documentation
>>    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...
>> 
> 
> Done:
> 
> https://www.linuxfoundation.org/collaborate/workgroups/openprinting/cups-filters
> 
> and linked from appropriate places on the front page
> 
> http://www.openprinting.org/
> 
>   Till
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[Alex Korobkin]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

2013/6/19 James Cloos <cloos@jhcloos.com>

>
> (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.)
>
>
Just for the record, calling pdftops with -level2 is hardcoded into
cups-filters
(see a snippet from pdftops.c below):

      if (renderer == PDFTOPS)
        /* Do not emit PS Level 3 with Poppler, some HP PostScript printers
   do not like it. See https://bugs.launchpad.net/bugs/277404. */

-Alex

[-- Attachment #2: Type: text/html, Size: 1138 bytes --]

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

[James Cloos]

>>>>> "AK" == Alex Korobkin <korobkin+op@gmail.com> writes:

AK> Just for the record, calling pdftops with -level2 is hardcoded into
AK> cups-filters

Till fixed that with revno 7069.

Now it checks for manufacturer =~ /^(HP)|(Hewlett-Packard)$/ and nickname eq 'laserjet'
before forcing level2.

Thanks Till.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

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

[James Cloos]

>>>>> "MS" == Michael Sweet <msweet@apple.com> writes:

>> PostScript printers are still more common than PDF printers.

MS> Most PostScript printers also support PDF these days.

I get a lot of ads for printers in the $500-$2500 range.  And try to
help those looking to use their new printer with linux, which involves
researching said printers’ capabilities.

I still see most lines avoiding hard drives on all but the high end (of
each line, that is).  I also haven't seen a manual which claims pdf
support w/o the often optional drive.

I doubt most but the highest-end of a given printer line.  I doubt even
more that many add a hard-drive after the fact.  (Especially since they
seem always to be special-order, never an in-stock item.)

MS> In fact, this year saw the introduction of some printers that
MS> support PDF but *not* PostScript.

PDF where no PDL strode before is very welcome.  And I cannot wait for
full ipp-everwhere support from everybody.

MS> And of course MOST printers sold in the last 20 years have had
MS> neither PostScript nor PDF support...

And for those I wrote that the filters should have gs render the ps
directly to raster, not first to pdf and then on to raster.  Not to
mention that most of those MOST printers likely were not accounted
as 5-year depreciation capital investments.  And some might not last any
longer in serivce than their initial ink cartridges. :)

And thus are not the sort of long-lived legacy printer I, primarily,
wrote about.

PS: Thanks for joining the thread; I hoped you'd have some insights on
    the matter.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

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

[Michael Sweet]

James,

On 2013-06-19, at 7:00 PM, James Cloos <cloos@jhcloos.com> wrote:
>>>>>> "MS" == Michael Sweet <msweet@apple.com> writes:
> 
>>> PostScript printers are still more common than PDF printers.
> 
> MS> Most PostScript printers also support PDF these days.
> 
> I get a lot of ads for printers in the $500-$2500 range.  And try to
> help those looking to use their new printer with linux, which involves
> researching said printers’ capabilities.
> 
> I still see most lines avoiding hard drives on all but the high end (of
> each line, that is).  I also haven't seen a manual which claims pdf
> support w/o the often optional drive.

Generally speaking, any new printer that supports PDF supports it without a hard drive. Most of HP's and Lexmark's laser printers support PDF now, and they all do it without a hard drive. The $229 OfficeJet 276 (an inkjet printer) supports PDF and has no hard drive - everything is stored in RAM (about 40MB available in that particular printer).

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

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

[James Cloos]

>>>>> "MS" == Michael Sweet <msweet@apple.com> writes:

MS> Generally speaking, any new printer that supports PDF supports it
MS> without a hard drive.

That is news.

MS> Most of HP's and Lexmark's laser printers support PDF now,
MS> and they all do it without a hard drive. 

Interesting.  Those two are among the few brands from which I don't get
ads and haven't recently researched. 

MS> The $229 OfficeJet 276 (an inkjet printer) supports PDF and has no
MS> hard drive - everything is stored in RAM (about 40MB available in
MS> that particular printer).

s/276/251/g for the $229 price point.

They (the 251 and the 276) are the first I've seen to spec "native PDF".

Running pdf from ram is definitely new.  I hope it is a trend.

Does it get ipp right?  Including with TLS?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

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

[Michael Sweet]

James,

On 2013-06-20, at 2:23 AM, James Cloos <cloos@jhcloos.com> wrote:
> ...
> Running pdf from ram is definitely new.  I hope it is a trend.
> 
> Does it get ipp right?  Including with TLS?


Yes.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair