Unscannable greyscale Barcode Zebra CPCL 203 DPI on CUPS 2.2.7 (works well on CUPS 1.3.9)

[birrageb]

Change darkness from 20 to 1 don’t help! (same result)

Same PPD File on both CUPS Servers
*PCFileName: "ZEBRACPL.PPD"
*ModelName: "Zebra CPCL Label Printer"

We use Same filters on both CUPS Servers
Started filter /usr/lib64/cups/filter/pstops (PID 16972)
Started filter /usr/lib64/cups/filter/pstoraster (PID 16973)
Started filter /usr/lib64/cups/filter/rastertolabel (PID

CUPS 1.3.9 SLES 11.3
ghostscript-omni-8.62-32.34.1
ghostscript-x11-8.62-32.34.1
ghostscript-library-8.62-32.34.1
ghostscript-fonts-std-8.62-32.34.1
ghostscript-fonts-other-8.62-32.34.1

CUPS 2.2.7 SLES 15.2
ghostscript-x11-9.52-3.32.1.x86_64
ghostscript-9.52-3.32.1.x86_64
ghostscript-fonts-std-9.06-14.3.1.noarch
ghostscript-fonts-other-9.06-14.3.1.noarch
ghostscript-fonts-std-converted-9.06-14.3.1.noarch

In web GUI from CUPS 2.2.7 the option to chnage the resultion is not visible.
We used lpadmin -o to set the resultion to the same value 203 DPI.

THANK YOU IN ADVANCE :-)

[jsmeix]

As far as I know you cannot use "same filters on both CUPS servers"
because .../cups/filter/pstoraster does no longer exist and is
replaced by /usr/lib/cups/filter/pdftoraster in the cups-filters RPM.

In general the whole print job filtering process was changed from
PostScript centric filtering to PDF centric filtering, see in particular
the section "PDF: The recent printing data format" in
https://en.opensuse.org/Concepts_printing

So the actual filtering programs (some /usr/lib/cups/filter/* are only wrappers)
are different from SLE11 to SLE15 and also the data format is different
from PostScript to PDF.

There are only minor visible differences in the output in your
https://user-images.githubusercontent.com/75418422/100988674-423ecd80-3550-11eb-94a5-447c1cd51f85.jpg
(a bit too "fat" black stripes that make the white stripes too narrow)
which could be whatever unfortunate side-effect of whatever conversion
in whatever filtering program - nothing what looks obviously wrong - so such
delicate/subtle issues are normally unnoticed by usual testing.

Finding the root cause means dissecting the filtering chain
(i.e. dissecting the Unix/Linux pipe of filtering programs)
and inspecting the output of each of the filters
(which is the input of the next filter in the pipe/chain)
as described in the section "A filter that sends its input into a file for debugging" at
https://en.opensuse.org/SDB:Using_Your_Own_Filters_to_Print_with_CUPS

When you found out which one of the filtering programs makes the
black stripes a bit too "fat" in its output compared to what it was in its input
then you only found which filtering program it was but you didn't found
why that program produces a bit too "fat" black stripes nor how to avoid
that it produces a bit too "fat" black stripes.

I know this all doesn't sound promising
but it is what I think how things are from my current point of view.
Perhaps I might get a better idea some time later - but no promises.

Personally I never had nor do I have any label printer
so I have no personal experience with label printers.

What I noticed is that usually label printers are used in "raw" mode
(i.e. a special label printing application program produces the right data
that makes a specific label printer model print so no filtering is needed), cf.
https://en.opensuse.org/SDB:CUPS_in_a_Nutshell#.22raw.22

So I wonder why in this case the complicated stack of
CUPS and cups-filters filtering is used?

Because I have no personal experience with label printers
all what I wrote here are only my theoretical assumptions.

Perhaps someone with personal label printer experience
could provide some more and actually helpful information
how one could solve such an issue in practice?

[birrageb]

Thank You for your input.

As first step we used/tested the PDF centric filtering as following:

/usr/lib/cups/filter/gstopdf (PID 29947)
/usr/lib/cups/filter/pdftopdf (PID 29948)
/usr/lib/cups/filter/gstoraster (PID 29949)
/usr/lib/cups/filter/rastertolabel (PID 29950)

But the same bad result.
we thought the result would be better with less amount of filters

[michaelrsweet]

This is an issue of antialiasing with current versions of Ghostscript. I have workarounds for this queued up in LPrint and the OpenPrinting CUPS project.