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

Michael Sweet <[email protected]> Sat, 7 May 2022 09:09:50 -0400
Newsgroups	dev.linux.lists.printing-architecture
Message-ID	<[email protected]>
Till,

> On May 7, 2022, at 3:05 AM, Till Kamppeter <[email protected]> wrote:
> ...
>>> Which sufficiently free PDF interpreter will you put at MuPDF's place?
>> Xpdf/Popper are GPL2, which fit the bill.
>> 
> 
> So GPL2 is OK and AGPL of Ghostscript/Artifex not? Why?

The GPL2 terms still allow companies, as well as individuals, to use and combine software freely.

The AGPL terms are specifically written to prohibit combining of software without either providing the combined software under the GPL/AGPL or seeking alternative licensing from the developer. Unfortunately, what defines a combined work is somewhat ambiguous, so one could argue that making use of non-free Wi-Fi firmware on a system that accepts print jobs over Wi-Fi violates the AGPL of Ghostscript.  I doubt that Artifex would push for such a legal interpretation, but they've chosen the AGPL and do license Ghostscript commercially.

As an organization under the Linux Foundation, I believe OpenPrinting has a responsibility to ensure that all users, including businesses, can use our work freely.  Unfortunately, the AGPL goes beyond *software* freedom and community (sharing) by explicitly limiting what you can do do with the software and effectively declaring that "all your base are belong to us."

(FWIW, I feel similarly about using GPL3 in OpenPrinting - its use is toxic to commercial distribution of OSS...)

> ...
>> It would be better to preprocess the PDF so that the PDF interpreter only has to rasterize content.
>> 
> 
> Sop something pdftopdf-alike?

Correct.

> ...
> By the way, we have seen some printers which do not like PDF output of QPDF (I got one bug report in the last days). Are there many more? Should we report a bug on QPDF? Or has it some general fault making reporting a bug on it not worthwhile?

Definitely need to report a bug, but it will be good to determine what the problem is...

> Note that PDF interpreters in printers can have quirks like PostScript interpreters. They also do not necessarily only hit QPDF output, but can also hit the ourput of Ghostscript, GTK, Qt, even PDFio.

Of course.

> So in my opinion we should not necessarily rush on getting rid of QPDF (we report bugs on QPDF compatibility issues to QPDF though) but better make sure that if a driverless printer is not able to print a PDF file that we smoothly fall back to raster, what you are currently fixing/have already fixed.

Right, and the support for raster fallback was designed into IPP Everywhere/AirPrint from the beginning, specifically because of our experiences with buggy interpreters.

(FWIW, I don't know whether Mopria talks about this at all, and Wi-Fi Direct doesn't address this...)

> I agree with replacing of QPDF by PDFio for sake of simplicity and getting rid of C++ though. As you probably I am much more comfortable with regular C.

Personally I'm fine with C++ code/syntax, but I also know that libstdc++ and the ABI/name mangling algorithms have gone through a number of incompatible changes over the years that has made distribution of compiled printer drivers/applications very difficult.  C just doesn't have those issues...

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