Print quality on Zebra

[mmoor3]

Printing barcodes from CUPS 2.2.7 using Zebra PPD 2.1.3 results poor print quality, barcodes are mashed together such they cannot be scanned. Same print from CUPS 1.4.2 prints without issue.

[zdohnal]

Hi @mmoor3 ,

are you able to reproduce with the latest CUPS 2.4b1 ? CUPS 2.2.7 is several years old... otherwise I would redirect you to your distro maintainers for more investigation.

It would be great if you attached the file you experienced the issue with and attached CUPS debug logs as .txt file here.

1. You enable logs by:

$ cupsctl --debug-logging

2. start catching the logs by:

$ tail -f /var/log/cups/error_log > log.txt

3. print the job
4. cancel the log capture by ctrl+c

@michaelrsweet do you have your Zebra printer at hand? Would you mind trying to print a barcode/smth to it to verify whether we are affected at the latest CUPS? I'm currently home office and our Zebra is at the office...

[jsmeix]

I think this issue could be a duplicate of https://github.com/apple/cups/issues/5863

[michaelrsweet]

@mmoor3 @zdohnal @jsmeix This is caused by a perfect storm of issues:

1. Many barcodes are embedded as JPEG images, with predictable issues in output quality.
2. Most RIPs (incorrectly) expand vector/font-based barcodes when rendering without anti-aliasing, which further exasperates the low resolution rendering issues
3. Many thermal label printers only offer 203dpi (8 dots per mm) which limits the allowable error before a barcode cannot be read
4. The current label driver does not offer a non-dithered mode, which can cause visible artifacts, particularly with barcodes.

There isn't anything that can be done about the first issue aside from reporting it to the shipping companies to have them stop using JPEG (PNG is a better choice...)

There are possibly some Ghostscript settings that could be used to minimize the second issue in my list (that would be a cups-filters issue).

For the last two issues, my LPrint printer application provides a non-dithered mode for printing bar codes, and I have pending changes to offer a virtual 600dpi mode specifically for preserving readable barcodes without changes to the various RIPs. That is where I plan on making any improvements and not to the legacy drivers.

[mmoor3]

Yes, this seems to be the issue, so I have pulled and compiled 2.4b1, but now anything I try to print says it is Unsupported

./lp: Unsupported document-format "text/plain" ./lp: Unsupported document-format "application/pdf"

Michael Moore | Principal Systems Administrator, Infrastructure Services IDEXX | One IDEXX Drive | Westbrook, Maine 04092 | o. 207-556-6246

[zdohnal]

Yes, this seems to be the issue, so I have pulled and compiled 2.4b1, but now anything I try to print says it is Unsupported ./lp: Unsupported document-format "text/plain" ./lp: Unsupported document-format "application/pdf"

Probably your compiled CUPS 2.4b1 isn't in the same place as OS installs the packaged CUPS - those document formats are supported by cups-filters (a different project), and the packaged CUPS is configured to be installed into such dirs which makes it work with cups-filters. This doesn't seem to happen with CUPS you've compiled.

@mmoor3 It would be great if you provided the debug logs for the job when you use CUPS from your OS - it will tell us which filters are used and which parameters are already passed into ghostscript - then I can take the parameters and contact ghostscript upstream regarding the second point Mike's mentioned.

To sum it up, once you provide the debug logs I will investigate with gs upstream and @tillkamppeter cooperation whether there is a possibility to mitigate the issue within filters without disruption of other printing use cases - so the mitigation, if possible, will be in cups-filters project.

In CUPS, we don't plan to focus on implementing mitigations, because printer drivers are going away soon and the issue is/will be mitigated in LPrint,

Original text: the printer application for label printers which don't support IPP Everywhere.

Updated text: the printer application for common label printers which don't support IPP Everywhere (Zebra printers are among them).

However we are still opened for pull requests, so if someone implements a mitigation in CUPS before LPrint delivers the mitigation and sends a PR to OpenPrinting CUPS, we will evaluate it for merging until LPrint provides the mitigation.

[mmoor3]

I was able to get 2.4b1 running based on what you stated, attached are the pdf and the debug log.

Thank you

Michael Moore | Principal Systems Administrator, Infrastructure Services IDEXX | One IDEXX Drive | Westbrook, Maine 04092 | o. 207-556-6246

[zdohnal]

@mmoor3 the github web ui probably can't show the attachments if the they're sent by email - your comment doesn't show any attachments as far as I can see. Would you mind going via web browser and attaching them as files via that?

Thank you in advance!

[mmoor3]

zebra.zip

[mmoor3]

The file has been added to the ui

Michael Moore | Principal Systems Administrator, Infrastructure Services IDEXX | One IDEXX Drive | Westbrook, Maine 04092 | o. 207-556-6246

[zdohnal]

@mmoor3 the txt file doesn't contain any logs regarding a print job. Please follow the steps as I've written above:

$ cupsctl --debug-logging
$ tail -f /var/log/cups/error_log > log.txt
(print a job where the output is garbled barcode)
(cancel the 'tail' command)

[mmoor3]

Here is an updated attempt cups.zip

[zdohnal]

Thanks for the logs @mmoor3 !

From the logs I see the relevant gstoraster logs:

D [18/Nov/2021:12:34:54 -0500] [Job 43] Ghostscript using Any-Part-of-Pixel method to fill paths.
D [18/Nov/2021:12:34:54 -0500] [Job 43] Ghostscript command line: gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -dAdvanceDistance=1000 -r203x203 -dDEVICEWIDTHPOINTS=288 -dDEVICEHEIGHTPOINTS=360 -dcupsBitsPerColor=1 -dcupsColorOrder=0 -dcupsColorSpace=3 -dcupsCompression=-1 -dcupsRowStep=200 -scupsPageSizeName=w288h360 -I/usr/share/cups/fonts -c \'<</.HWMargins[0.000000 0.000000 0.000000 0.000000] /Margins[0 0]>>setpagedevice\' -f -_

The first line especially rang a bell, so I looked into filter/gstoraster.c (cupsfilters/ghostscript.c) - cups-filters project provides a mitigation since version 1.11.4, which is done by setting 'CenterOfPixel' option to a print job. More info how to set it here.

@mmoor3 would you mind trying whether the setting the option does the trick for you? If not, I would pass this issue to cups-filters for more investigation.

[mmoor3]

I tried "-o CenterOfPixel" and "-o center-of-pixel" at command line as well as adding the following to the ppd file. All 3 attempts resulted in nothing coming out of the printer. A attached the log of the last attempt.

OpenUI CenterOfPixel/Center Of Pixel: PickOne OrderDependency: 20 AnySetup CenterOfPixel DefaultCenterOfPixel: true CenterOfPixel true/true: "" CenterOfPixel false/false: "" CloseUI: *CenterOfPixel log1.txt

[zdohnal]

@mmoor3 you've hit Ghostscript error during printing (as it is seen in logs) - it is because Ghostscript in your OS was updated to almost latest version, but it is not reflected in OS version of cups-filters. To be precise, newer ghostscript doesn't have .setfilladjust function, but only .setfilladjust2 - ghostscript is complaining about using undefined function, because it is no longer defined in gs library and still gstoraster tries to use it.

@jsmeix it would be great if cups-filters package was updated to make it work with new ghostscript (if the new ghostscript is in supported SUSE repos). Would you mind building and passing the testing RPMs with the fix (look for .setfilladjust string in cups-filters upstream git log) to @mmoor3 ?

[jsmeix]

@zdohnal thank you so much for your great analysis of the root cause!

@mmoor3 according to https://github.com/OpenPrinting/cups/issues/280 you use SLES15-SP2. In SLES15-SP2 we have currently cups-filters-1.25.0 cf. https://build.opensuse.org/package/show/SUSE:SLE-15-SP2:Update/cups-filters Searching its sources results

user@linux:/sources/cups-filters> find cups-filters-1.25.0 -type f | xargs grep 'setfilladjust'
cups-filters-1.25.0/filter/gstoraster.c:    cupsArrayAdd(gs_args, strdup("0 .setfilladjust"));

In the openSUSE Build Service (OBS) development project "Printing" https://build.opensuse.org/package/show/Printing/cups-filters we have currently cups-filters-1.28.8 and searching its sources results

user@linux:/sources/cups-filters> find cups-filters-1.28.8 -type f | xargs grep 'setfilladjust'
cups-filters-1.28.8/NEWS:       - gstoraster: Use ".setfilladjust2" instead of the
cups-filters-1.28.8/NEWS:         undocumented ".setfilladjust" PostScript command for
cups-filters-1.28.8/filter/gstoraster.c:    cupsArrayAdd(gs_args, strdup("0 0 .setfilladjust2"));

so things could work with cups-filters-1.28.8 from the OBS "Printing" project that we also provide for SLES15-SP2 for x86_64 architecture at https://download.opensuse.org/repositories/Printing/SLE_15_SP2/x86_64/

FYI: RPM packages from the OBS "Printing" project are not officially supported by SUSE, see the "Printing System Development Project" description on https://build.opensuse.org/project/show/Printing (click on [Show more] to see the whole description). When cups-filters-1.28.8 from the OBS "Printing" project works for you and if you have a SUSE support contract for your SLES15-SP2 you should contact SUSE via your official support contact method and ask for an officially supported cups-filters version upgrade or a fix for the current cups-filters-1.25.0 in SLES15-SP2.

[zdohnal]

@mmoor3 please let us now here whether the newer cups-filters works for center-of-pixel option and the printed barcode is better - I would like to know there is a need for other mitigation in cups-filters or center-of-pixel does the trick.

[zdohnal]

@jsmeix well the similar thing happened for me during ghostscript update to newer version in RHEL 8, but ghostscript maintainer notified me of change in advance, so we were able to push the updated cups-filters with new ghostscript together... so the analysis isn't a new one :) .

[jameshilliard]

In CUPS, we don't plan to focus on implementing mitigations, because printer drivers are going away soon and the issue is/will be mitigated in LPrint, the printer application for label printers which don't support IPP Everywhere.

FYI based on this discussion there is no migration path being provided by LPrint for retail/industrial printers, only home/office printer protocols appear to be on the roadmap. It seems a new project is needed for handling common retail/industrial use cases for printers.

[zdohnal]

@jameshilliard Zebra printers and the specific mitigation from this issue are on LPrint roadmap (as Mike's written above), so this issue is not affected. However I've updated the text you reply to to prevent more misunderstandings.

[mmoor3]

After upgrading cups-filters to 1.28.1 we are now printing labels that can be scanned

[zdohnal]

@mmoor3 thank you for letting us know, closing the issue.