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

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

> On May 6, 2022, at 3:18 PM, Till Kamppeter <[email protected]> wrote:
> ...
> and then will all build libcupsfilters with PostScript support. So perhaps better move the PostScript support code into the PostScript Printer Application. WDYT?

Long term that is probably the best approach.  But I suspect CUPS 2.x will be around for a while yet so I wouldn't jump at moving things around until we are done supporting cups-filters.

>> The "exotic" image formats are already supported by desktop (Gimp, etc.) and command-line (Imagemagick, etc.) applications that can handle printing.
>> 
> 
> The support for them is still lurking around in libcupsfilters 2.x. Probably they will never get used. I could remove them now, making use that we are starting a new generation (2). WDYT?

Up to you, but it would make sense.

>>> 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?
> 
> See this issue: https://github.com/apple/cups/issues/6022
> 
>>> 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.
> 
> The printers are the HP LaserJet M14, M15, M16, M17

LaserJet *Pro* M14-M17, and they do not appear to be manufactured anymore (looks like there are few still available from Amazon, just not from HP directly that I can see) and have been replaced by the M110 series which *does* support AirPrint and Apple Raster.

Anyways, if that is the extent of the PCLm-only printers we need to support, I am not convinced we need to add the complexity of supporting PCLm - it's not just a matter of the format, you also have to support the banding, etc. attributes and values.

> ...
>>> 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.
> 
> Which sufficiently free PDF interpreter will you put at MuPDF's place?

Xpdf/Popper are GPL2, which fit the bill.

> ...
> Which is the PDF rasterizer which should be used then? Or do we need a PDF pre-processor like pdftopdf for that?

It would be better to preprocess the PDF so that the PDF interpreter only has to rasterize content.

>>> - 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.
> 
> How is it planned to get implemented in CUPS 3.x.

In the transform program.

>>> - 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.
> 
> OK, what is your alternative?

PDFio.

> ...
> So I need to know whether it is still worthwhile to invest in cups-filters or whether I should perhaps put it into maintenance mode and move to for example working on PDFio to make it flatten forms and do other things to replace the pdftopdf filter?

You'll need to support cups-filters for a while yet, obviously, and it would be useful (even for cups-filters) to use PDFio instead of QPDF for PDF filtering...

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