Re: [Printing-architecture] CUPS 3.x: How we make it converting job data formats?

Michael Sweet <[email protected]> Fri, 6 May 2022 14:22:17 -0400
Newsgroups	dev.linux.lists.printing-architecture
Message-ID	<[email protected]>
Till,

> On May 6, 2022, at 11:14 AM, Till Kamppeter <[email protected]> wrote:
> 
> Seems that your plans are to discontinue cups-filters and to include a new from-scratch filter approach in CUPS 3.x. Am I right?

I'm not sure at this point.  I *do* know that I'd like to see us focus out efforts on core file formats and a minimal set of dependencies for converting them - IMHO there are too many combinations to test and support properly.

> I think this is not a good idea. cups-filters contains 2 decades of hard work and even if we do not make use of its full functionality we should not throw it overboard.

I don't think I suggested that.

> First, to the formats we will need.
> 
> PostScript and all these old, exotic image formats which older CUPS versions and cups-filters support we indeed do not need.

Well, certainly the PS printer application needs PostScript support.  The "exotic" image formats are already supported by desktop (Gimp, etc.) and command-line (Imagemagick, etc.) applications that can handle printing.

> PDF, JPEG, PNG, and text is good enough, especially as desktop applications usually send PDF. Output should be PDF, Apple Raster. PWG Raster, and PCLm. PCLm is also actually needed as there are PCLm-only printers which fulfill the driverless printing standards.

PCLm only satisfies Wi-Fi Direct and Mopria.  Can you name a single PCLm printer that also doesn't support AirPrint or IPP Everywhere?

> We discovered such printers recently. I really do not want to have to provide a Printer Application for printers which fulfill driverless printing standards.

Make and model please.

> Also there is some useful functionality compared to tools/ipptransform.c which I like to keep:

ippsample's prototyping tool?  That's effectively my model for the new 3.0 filtering/transform front-end, although I will shortly be eliminating its usage of MuPDF - that library's API is far too unstable to depend on and uses an incompatible license for production.

> - Ghostscript is the PDF renderer best optimized for printing. The interpreter got recently converted to be completely written in C, improving its performance and resource usage. So calling Ghostscript as external executable (to not need to worry about license compatibility) could improve things compared to MuPDF (and AFAIR MuPDF and Ghostscript have the same license).

We CANNOT rely on Artifex software anymore.  AGPL3 makes it a non-starter for anyone using CUPS on embedded or cloud platforms - unlike GPL(2/3) you can't just pipe the output, since AGPL applies to the work as a whole (total overreach IMHO, but it's their software...)

I have no problem with Ghostscript being an option, but we need to make sure CUPS can be used freely by everyone, not just the True GNU.

> - Ghostscript produces all the 4 driverless printing output formats: PDF (not actually needed in our use case), Apple Raster (I have added it in 9.56.0), PWG Raster, and PCLm, so no post-filtering after Ghostscript needed, the output of Ghostscript can be directly passed on to the printer. For Snaps and other sandboxed packages or for IoT Ghostscript can be compiled with only the needed output devices (I do this in the Printer Application Snaps).

Ghostscript may be able to rasterize PDF content, but it doesn't handle the transform/imposition/watermarking functionality that is often used.

> - CUPS provides some extra functions in page management: N-up, even/odd, mirror, ... via the pdftopdf filter. We should conserve them.

Again, I wasn't suggesting that functionality would go away.

> - The pdftopdf filter flattens filled PDF forms and annotations, which assures that the filled in text actually gets printed by the printer, independent whether the printer prints PDF directly or when need to to convert incoming PDF to some raster format.

Right, but the current QPDF-based filtering seems to cause problems for some printers.

> - Thorough page geometry tests and fixes have been performed on all filters of cups-filters recently. All combinations of the print-scaling and number-up attributes should work, and with both standard portrait and also landscape-oriented (long-edge-first) paper size settings.

I'm glad to hear that.

________________________
Michael Sweet
signature.asc (application/pgp-signature, 833 B)