Driverless no longer supports pdf

[szlt5]

@tillkamppeter

I have reported the bug at https://github.com/OpenPrinting/cups-filters/issues/574

The Everywhere & the old version driverless (in the cups-filter-1.27) can generate "application/vnd.cups-pdf application/pdf x -" in the ppd file. But the new version driverless (in the cups-filter-2.0) cannot generate the "application/vnd.cups-pdf application/pdf x -" in the ppd file.

And I have compared the function ppdCreatePPDFromIPP2() vs the ppdCreateFromIPP2(). The behavior changed. Is it possible to adjust the priority of application-pdf to be higher than image/ufr in the ppdCreatePPDFromIPP2()?

[szlt5]

The reason why we prefer pdf is : when the "image/urf" is selected, the copies will be expanded on the soft side (pdftopdf or imagetoraster filter). Suppose the a document (Page1,2,3) is printed with copies = 2 and staple = on. Expect result: print out two copies (Copy1: Page1,2,3 with staple on, Copy2: Page1,2,3 with staple on). Actual result is: Page1,2,3,1,2,3 with staple on.

[szlt5]

Prefer raster formats to PDF: https://github.com/OpenPrinting/cups-filters/issues/331

[szlt5]

Prefer image/urf formats to pwg: https://github.com/OpenPrinting/cups-filters/issues/498

[zdohnal]

@szlt5 I'm really sorry, but I can't imagine the situation... would you mind scanning the actual printout, marking where is the problem in it and explain (ideally in some pictures) what is the desired output? Because IMO you can put two staples regardless, unless you use duplex (which you haven't mentioned) - then printing in duplex as one document would be a problem, because 1st page of the second copy gets on the other side of 3rd page of the first copy. Either way, it looks like an issue with generating output in filters, not a something which can't be fixed other way than prefer the PDFs doc format.

Ideally, I could see this could be configurable (a file read by libppd and where user can define what document format to prefer) or having document-format settable for a job.

@michaelrsweet @tillkamppeter WDYT? Is the behavior mentioned by @szlt5 downside of using raster and can be only fixed by switching document format preference, or a bug fixable in filters? What do you think configurable preference of document formats and possibility to set document-format for a job?

[szlt5]

I'm sorry for not describing the issue clearly.

[Test Data]: A document with 3 pages [Print Setting]: copies=2, duplex=One Sided, collate=true, staple=on [Expected Print Result]: print out two copies (Copy1: Page1,2,3 with staple on, Copy2: Page1,2,3 with staple on). [Actual Print Result of driverless in the cups-filters-2.0.0]: Page1,2,3,1,2,3 with staple on

Notes: Everywhere & the old version driverless (in the cups-filter-1.27) print results as expected.

[szlt5]

Below is the printer's IPP capability. driverless_capability.txt

[michaelrsweet]

@zdohnal Raster + finishings is a recipe for trouble. The job-pages-per-set attribute is intended for telling the printer how many raster pages per "set" for finishing purposes, but currently there is no way for a filter to pass that information to the backend.

My recommendation is to prefer PDF, when supported, and to make sure that cups-filters produces correct PDF so that the "problematic" printers don't error out. The fact that some printers are not following the AirPrint/IPP Everywhere requirement to set the "document-format-error" or "document-unprintable-error" values in "job-state-reasons" is a reason to contact those vendors to get firmware updates, not to hobble every PDF printer out there and deliver a sub-optimal print experience.

[zdohnal]

@michaelrsweet does "document-unprintable-error" cover font problems in the output? The reason why I was happy for raster was it solved occasional font problems when printing a document which was created on Windows (I'm looking at you, Czech tax documents!). It looks to me such messages appear when the job gets completely botched and some missing Czech accents is nothing too critical to stop the job :( ...

@michaelrsweet I agree that such issues should be solved by manufacturer in firmware, but sometimes you are in time pressure (again, f.e. tax deadline approaching :) for normal user ) and now you can't print them at all or correctly - manufacturer probably won't be able to fix it that fast, so you are lost. Unless you know ghostscript command to regenerate PDF, but how many normal users knows about it and how many common printer users use command line...

It would be really great if final document-format was settable for such cases as workaround. Otherwise, what would be a workaround for such cases, until the firmware is fixed?

[michaelrsweet]

@zdohnal Missing characters/fonts are not enough (how to handle those issues are defined in the PDF specs), but corrupt fonts should trigger an error.

WRT workarounds, the "driverless" stuff could provide two alternative drivers for PDF printers ("standard" that prefers PDF and "raster-only" that only supports raster) so that users can configure things to use raster.

[szlt5]

WRT workarounds, the "driverless" stuff could provide two alternative drivers for PDF printers ("standard" that prefers PDF and "raster-only" that only supports raster) so that users can configure things to use raster.

Looking forward to the fix and I am glad to supply further testing for the fix.

[zdohnal]

@szlt5 any PR is welcome :)

[zdohnal]

@zdohnal Missing characters/fonts are not enough (how to handle those issues are defined in the PDF specs), but corrupt fonts should trigger an error.

What is the difference between missing chars/fonts and corrupted ones? AFAIK the first puts empty rectangles instead of chars or completely ignores them, the other garbles the character. IMO both is unacceptable output for official documents and the job should not be printed as it is at the moment (might be retried as raster if the device returns the correct error).

What I don't find as an error when the garbled printout is out is if the printer tries to substitute missing font/char, but its font substitution is buggy... then the bug is on font substitution in printer... now when I'm thinking on it, I guess printer firmware has some default for such cases (like some English default font), and if the font in the document is not found and there is no defined sub, it tries the default one and hopes for the best...

WRT workarounds, the "driverless" stuff could provide two alternative drivers for PDF printers ("standard" that prefers PDF and "raster-only" that only supports raster) so that users can configure things to use raster.

Yeah, the same can be provided by CUPS for everywhere printers - if some printer does not work correctly over PDF, we can switch to raster.

In the meantime, I've changed libppd to prefer PDF over rasters and checked whether the old issue is present - both (everywhere and driverless) worked well. So IMHO we can switch to prefer PDF at the moment in libppd, and later implement switching between final document format, both in CUPS and libppd - because IMO such switching can be useful even for CUPS 3.x - printers support several document formats, so destination generators should not restrict user (who knows what he's doing) to send a different format to the printer.

[michaelrsweet]

@zdohnal

What is the difference between missing chars/fonts and corrupted ones?

Missing characters are glyphs that are not present in the font. PDF renderers can substitute (from a built-in font) or display the empty glyph. This might show up in the "errors-count" attribute and the 'errors-detected' reason in "job-state-reasons", but it wouldn't be enough to abort the job.

Corrupt fonts/characters cannot be rendered at all because the data is corrupted.

[szlt5]

@zdohnal It seems that the commit has not been merged into the main branch :)

[zdohnal]

@szlt5 it's waiting on review. @tillkamppeter ?

[tillkamppeter]

Just preferring PDF would solve the mentioned finishing problems, but on the other size cause problems on printers with bugs in their PDF implementation and also font-related problems in some cases.

What is also worthwhile to test is to send raster-only PDF to PDF-accepting printers. This at eliminates most rendering-related problems with the printers but as it is PDF, the finishing issues get solved.

One should give this a try.

libcupsfilters is capable of generating raster-only PDF. For this we could choose application/pclm as output format but the PPD generator has to generate the cupsPCLM... lines based on general printer IPP attributes and not based on PCLM-related IPP attributes (which are not necessarily there. Or we create a new raster-PDF MIME type which makes the filters outputtting raster-only PDF (sending PDF through the gstopdf filter with the cfFilterGhostscript() filter function called with CF_FILTER_OUT_FORMAT_PDF_IMAGE output format.

For the time being we can go back to preferring PDF output.

[szlt5]

@zdohnal How's the merge going?

[zdohnal]

@szlt5 If you check the merge request, it is waiting for review.