search

OpenPrinting / cups-filters

filters, backends, driverless utility, ... - Everything which CUPS 2.x needs to be used on non-Mac systems
Apache License 2.0
157 stars 126 forks source link

Misalignment of rear-side printing using double-sided mode on Samsung ProXpress M3820ND #497

Open Chapmip opened 1 year ago

Chapmip commented 1 year ago

Set-up:

Linux Mint 19.1 Cinnamon 64-bit (also occurred when testing Linux Mint 21.1 Cinnamon 64-bit) CUPS versions since May 2019 or earlier (currently CUPS 2.2.7) Samsung ProXpress M3820ND A4 paper, double-sided printing

Problem scenario:

  1. When printing to A4 sheets in double-sided mode using CUPS without using the Samsung printer driver, the print output on the rear side of the sheet is displaced to the right by 10mm compared to that on the front side.
  2. When printing the same way from the same platform after installing the Samsung Print Driver for Linux (V1.00.39_01:17, Sep 1, 2017) and configuring a print queue with this driver, the print output on the front and rear sides is correctly aligned.
  3. This issue does not occur when printing to the same printer from Windows, Android and Chromebook clients -- so it appears to be CUPS-specific.

Further analysis:

  1. I originally described this issue in this posting in 2019 in the Linux Mint forums. The posting contains detailed information including the outputs from various diagnostic commands. At that time, I worked around the issue (hence shown as "[SOLVED]") by installing the Samsung driver and using a CUPS print queue associated with this driver.
  2. I re-visited this scenario in January 2023 whilst testing out the latest Linux Mint installation (Linux Mint 21.1). The same issue occurred when using "driverless" printing for this printer under CUPS. Once again, I could work around the issue by installing the Samsung printer driver and creating a print queue that adopted it.
  3. My concern now is that CUPS is intending to drop support for printer drivers, so the workaround using the Samsung driver may become unusable in the near future.

Images: Below is the front side of a print using CUPS without the Samsung printer driver. The left margin measures 5mm on the A4 sheet: img-230104163815-001

Below is the rear side of a print using CUPS without the Samsung printer driver. The left margin measures 15mm on the A4 sheet (i.e. output shifted right by 10mm): img-230104163904-001

Below is the front side of a print using a CUPS print queue associated with the installed Samsung printer driver. The left margin measures 5mm on the A4 sheet as before: img-230104163925-001

Below is the rear side of a print using a CUPS print queue associated with the installed Samsung printer driver. The left margin correctly measures 5mm on the A4 sheet (i.e. aligned with the front side): img-230104164003-001

sourabh1952 commented 1 year ago

@Chapmip is the problem printer specific means only for Samsung ProXpress M3820ND printer ?

Chapmip commented 1 year ago

@sourabh1952 I'm unable to answer that question as I only have access to this one model of Samsung printer.

I imagine that some other Samsung printers may use the same print engine and would experience the same problem, but I simply don't know.

I therefore raised the issue for this specific Samsung model, in the hope that the issue may be readily reproducible on this and perhaps other Samsung models. The Samsung driver that solves the problem (see link above) appears to be generic (i.e. not targeted at this specific model of printer).

sourabh1952 commented 1 year ago

@Chapmip can you please share your error log in debug mode and share your ppd file in .txt format.

Chapmip commented 1 year ago

I'm not familiar with CUPS, so I'm hoping that I've taken the right steps (see attachments) to secure a debug error log for a double-sided A4 print with the Samsung printer. I carried these out using Linux Mint 21.1 Cinnamon (64-bit) edition. I've attached both my terminal command input and the error log output here as separate text files.

When you say "your ppd file", I assume that you mean the PPD file from the Samsung Print Driver for Linux (V1.00.39_01:17, Sep 1, 2017) download -- this is the one that produces correctly aligned output when installed. I've attached that file here as well.

Debug Error Log:

terminal_commands.txt error_log.txt

PPD File from Samsung Driver for Linux:

Samsung_M332x_382x_402x_Series.ppd.txt

I hope that's helpful!

michaelrsweet commented 1 year ago

Moving this over to the cups-filters project since CUPS itself isn't responsible for generating the raster data for these printers.

tillkamppeter commented 1 year ago

@Chapmip could you attach your file /etc/cups/ppd/Samsung_M332x_382x_402x_Series_SEC84251977B9D1.ppd (please rename the copy to be attached to have .txt in the end so that GitHub accepts it).

Chapmip commented 1 year ago

@tillkamppeter Please see attached file (modified to .txt as requested).

From Linux Mint 21.1 Cinnamon (64-bit) edition:

Samsung_M332x_382x_402x_Series_SEC84251977B9D1.ppd.txt

sourabh1952 commented 1 year ago

@Chapmip as much I read about the files and filters which are responsible here, I didn't got any such indication in issue with margin in even/odd pages. Are you provided any margin from the terminal or used the default one. If you not set margin from terminal can you please specify some margin from the terminal. If the issue persists then let me know.

Chapmip commented 1 year ago

@sourabh1952 Thank you for looking into this further. I haven't changed any margin settings, so the settings have always been the defaults.

I have not been able to find any option for changing the print margins differently on "even" vs "odd" pages. I found some margin settings (see below) but they apply to all pages.

"Printer Properties" window on Linux Mint

The only options for margins that I found here were under "Job Options":

Text Options:

Characters per inch:  10.00
Lines per inch:        6.00
Left margin:           0 points
Right margin:          0 points
Top margin:            0 points
Bottom margin:         0 points

I did a "Print Test Page" from the "Printer Properties" window and observed that the "even" page was, as expected, incorrectly displaced to the right compared to the "odd" page.

I then tried this in the "Printer Properties" window:

  1. Changed all four margins above from 0 points to 50 points
  2. Did "Print Test Page" from the "Printer Properties" menu

I observed that:

  1. On both sides of the double-sided page, the rendered print was in the same position as when the margins were "0 points" all round
  2. The rendered print on the "even" page was still incorrectly displaced to the right compared to the "odd" page

Printing from an Application

I also tried adjusting the margin settings in Firefox. Those caused the body text to move, but with the same incorrect displacement overall to the right on the "even" page. The header and footer remained in exactly the same positions as before I changed the margins, also with the incorrect displacement to the right on the "even" page compared to the "odd" page.

CUPS Web interface

I logged into localhost:631. In the output below, I have replaced the printer-specific "SEC" string with "xxxxxxxxxxxxxxx".

From "Manage Printers":

Samsung_M332x_382x_402x_Series_xxxxxxxxxxxxxxx_

Samsung_M332x_382x_402x_Series_xxxxxxxxxxxxxxx_ (Idle, Accepting Jobs, Not Shared)

Description:    Samsung_M332x_382x_402x_Series_xxxxxxxxxxxxxxx_
Location:   
Driver:         M332x 382x 402x Series (grayscale, 2-sided printing)
Connection:     ipp://xxxxxxxxxxxxxxx.local:631/ipp/print
Default:        job-sheets=none, none media=iso_a4_210x297mm sides=two-sided-long-edge

"Print Test Page" from CUPS produced the same result as above -- the "even" page output was incorrectly displaced to the right compared to the "odd" page.

I couldn't find any option in the CUPS Web interface to change any margins.

From "Set Default Options":

Set Default Options for Samsung_M332x_382x_402x_Series_xxxxxxxxxxxxxxx_

General

Media Size:        A4
Media Source:      Tray 1
Media Type:        Plain Paper
2-Sided Printing:  Long-Edge (Portrait)
Print Quality:     Normal

(I found nothing relevant under "Banners" or "Policies")

I'm not sure how helpful that is. Unfortunately, I think I've reached the limits of my understanding of what tests to try.

sourabh1952 commented 1 year ago

@Chapmip in your points you say that you add 50 points to all the four margins but the output is same as 0 points. Is this means that their is no affect in the new margin of the page when you added extra 50 points, the new margin(50 points) is same as old one(0 points). Am I understand right or not?

Chapmip commented 1 year ago

@sourabh1952 That is correct. However, the setting that I changed in the Linux Mint "Printer Properties" window was under the title "Text Options", along with settings for "Characters per inch" and "Lines per inch". I am not sure whether any of these settings affect the graphical output from "Print Test Page". Maybe it doesn't change that, so it wouldn't change the problem either.

I just tried again and had the same result. Specifically, I did the following in the Linux Mint "Printer Properties" window:

  1. Checked that all of the margins under "Text Options" were initially to "0 points"
  2. Printed a double-sided "Printer test page"
  3. Changed all of the margins under "Text Options" to "75 points" and clicked "Apply"
  4. Printed another double-sided "Printer test page"

I put both sheets together and held them up to the light. They aligned exactly -- no change.

Maybe this is the wrong test.

tillkamppeter commented 1 year ago

@Chapmip could you run the following commands:

ipptool -tv ipp://SEC84251977B9D1.local:631/ipp/print get-printer-attributes.test > attrs.txt
ipptool --ippserver ippserver-attrs.txt ipp://SEC84251977B9D1.local:631/ipp/print get-printer-attributes.test

Please attach both output files. The former is more human-readable. With the latter, we can emulate your printer for further investigation via

ippeveprinter -a ippserver-attrs.txt testprinter

Find its URI via

driverless --std-ipp-uris
Chapmip commented 1 year ago

@tillkamppeter I ran the first command and it produced an "attrs.txt" file, which I have attached here.

attrs.txt

The second command, though, fails with the error message:

ipptool: Unknown option "--".
Usage: ipptool [options] URI filename [ ... filenameN ]

Was I supposed to enter that second command line literally, as I did?

I don't see where a different URI needed to be entered in either of the above commands. The ipp://SEC84251977B9D1.local:631 seemed to find the printer okay in the first command.

I also tried driverless --std-ipp-uris, but it failed too with the error message:

ERROR: Invalid URI: --std-ipp-uris

I tried ipptool --version and it returned:

CUPS v2.2.7
tillkamppeter commented 1 year ago

@Chapmip it seems that your CUPS version is too old to provide all the latest and greatest debugging methods. The described methods work on Ubuntu Lunar Lobster (upcoming 23.04) and probably need at least CUPS 2.4.x. I do not remember now in which version of cups-filters I introduced the option --std-ipp-uris for the driverless utility.

So due to this fact, we only can check through your atts.txt manually, but this could already be of help.

If you have also a newer Linux at hand, like Ubuntu 22.04 LTS (Jammy Jellyfish) you could try the mentioned commands there.

tillkamppeter commented 1 year ago

@Chapmip having looked through your attrs.txt I did not see any hint on special treatment to be applied to duplex printing. The urf-supported attribute contains DM1, meaning "normal" back sides, or do not do anything different when printing the back side. This is expected as your printer understands Postscript which also means that it can hold a complete, rendered/rasterized page in memory, so no need for sending the back side data in any special order or arrangement.

Chapmip commented 1 year ago

@tillkamppeter Thank you for your further thoughts.

I just ran up a test build of Linux Mint 21.1, which is based on Ubuntu 22.04 LTS.

This time, ipptool --version yielded...

CUPS v2.4.1

... and the two commands both ran fine. Here are the outputs:

attrs.txt ippserver-attrs.txt

having looked through your attrs.txt I did not see any hint on special treatment to be applied to duplex printing. The urf-supported attribute contains DM1, meaning "normal" back sides, or do not do anything different when printing the back side. This is expected as your printer understands Postscript which also means that it can hold a complete, rendered/rasterized page in memory, so no need for sending the back side data in any special order or arrangement.

I'm wondering whether the root cause here might be a firmware bug within the Samsung ProXpress M3820ND printer (at least -- maybe also other models that use the same printing engine) that causes an incorrect offset to be applied on "even" pages -- at least, on A4 paper. That could happen if, for example, the code writers hard-wired an assumption about measurements based on the width of US Letter paper. As I understand it, that's 215mm wide compared to 210mm for A4 paper, which corresponds neatly (when doubled for a page-flip) to the 10mm offset that I'm seeing. Perhaps the Samsung driver contains a quiet workaround for this bug, which might then explain why the print renders correctly when I install this Linux driver, and why the output is also fine from a Windows PC (which presumably also imports the corresponding Samsung driver). In a nutshell, CUPS could be doing all the right things generically, but the printer messes it up when it's uncompensated by the vendor's driver.

I can work around this for now by installing the Samsung Linux driver and using that, rather than driverless mode in CUPS. My longer-term concern is whether I will be able to continue with this workaround in the future when, as I understand it, CUPS is dropping support for printer drivers and moving to a completely driverless model. Will there be any way for me to continue using the Samsung driver to work around this problem when that change happens?

I also wondered whether it might be possible to incorporate an adjustable parameter into the CUPS rendering for "even page horizontal offset" (normally zero, but changeable to perhaps -10mm in my case). I have no idea of how technically complex that might be, but presumably it would enable me to bring the two sides of a page back into line using driverless printing. It could also help anyone else who might be experiencing this problem with any given model of printer. I'm probably dreaming here about the benefit vs cost to the CUPS project of engineering such a tweak, but I thought I might as well ask! ;-)

Many thanks for the time and consideration by everyone concerned in this thread.

tillkamppeter commented 1 year ago

I have run the filters (of cups-filters 1.x and of libcupsfilters/libppd/cups-filters 2.x, current GIT master in both cases) manually with your PPD file and also got correct back sides. So your assumption of a firmware bug in the printer seems to be correct.

The bad thing is that the exercise we are all doing here is called driverless printing and Samsung is correcting their firmware bugs with a driver.

And if there are firmware problems, they are all different. You cannot add an option for back side mismatch adjustment and end up that it only fixes this model and there come several other bug reports similar to this one but the firmware bugs have completely different effects. So it will not actually be worthwhile to add such a feature to the filters.

We are about to improve the QA for the filters by adding new tests, but the maximum we can do is to check the PWG/Apple/CUPS Raster data which comes out at the end of the filter chain. We cannot see what the actual printer or some printer driver for a non-driverless printer does with this data.

For the future of CUPS 3.x not supporting classic CUPS drivers any more, we have already taken care:

So I hope this helps and that we from OpenPrinting are sustainable, keeping old printers working.

Chapmip commented 1 year ago

@tillkamppeter Thank you for your further investigations. I think we agree on the likely cause of the problem and why it doesn't show up using the proprietary driver -- it's a case of "two wrongs making a right" with the Samsung printer firmware and driver, rather than any bug in CUPS.

Thanks also for your explanation of the future roadmap for CUPS 3.x. I'll be curious to hear in due course about the configuration changes that I and others will need to make in order to continue using legacy printers and their drivers once that arrives.

debiantriage commented 1 year ago

For proprietary legacy CUPS drivers, like the one from Samsung, we have also a solution, the so-called Legacy Printer Application. It sees classically installed classic CUPS drivers, independent whether there is a classically installed CUPS 2.x on the system or not, and makes them available as Printer Application, so that CUPS 3.x sees and uses them.

So I hope this helps and that we from OpenPrinting are sustainable, keeping old printers working.

I think the innovation from OpenPrinting is remarkable in its scope and attention to the needs of users.

Regarding the Legacy Printer Application, I hope this understanding of mine is correct:

tillkamppeter commented 1 year ago
  • The Legacy Printer Application can be packaged as a .deb.

Yes, no problem. I have already created a DEB package for Ubuntu, pappl-retrofit, currently in Universe, intended to get promoted into Main. The DEB package of pappl-retrofit contains a binary package named legacy-printer-app which one simply installs and then one can create print queues in its web interface. It immediately sees all installed classic CUPS drivers (if from Debian, the printer-driver-... packages). You should back-sync this Ubuntu package into Debian (experimental for now as it needs 2nd-generation libcupsfilters and libppd packages).

  • Non-free packages from Brother (say) can be installed and be set up in the Legacy Printer Application being used with CUPS 3.x.

Yes, if they get installed where the standard, distro-installed CUPS looks for filters, backends, and PPDs, the Legacy Printer Application will see them and one can create a queue with it. CUPS itself (cups-daemon package) does not need to be installed for that. Only libcups (version 2, soon also version 3 is supported) needs to be installed.

  • Should it desire, Brother is relieved of the responsibility to produce its own Printer Application.

Yes, Brother does not necessarily create Printer Applications as their classic driver can be used with the Legacy Printer Application. But it is HIGHLY RECOMMENDED for manufacturers to create Printer Applications, as we will get all-Snap distributions, or immutable-core distributions. They require any package or application be installed in a supported sandboxed package format, like Snap or OCI containers, DEB packages are NOT supported, also direct-from-tarball installation or AppImage is not supported in such a case. This means that these distros DO NOT support proprietary printer drivers as of now.

  • Free Epson drivers not catered for by gutenprinter-printer-app can be accessed after the printer-driver-escpr package is installed on Debian/Ubuntu.

Yes, that is true. The Legacy Printer Application also makes the printer-driver-escpr package usable with CUPS 3.x, the same way as mentioned proprietary printer drivers, all printer-driver-... packages in general (but nearly all of these drivers are available as Printer Applications already, in the 4 retrofitting Printer Applications in the Snap Store).

Important note here for Debian packagers (@zdohnal): Please change ALL the printer-driver-... to NOT depend on cups-daemon any more and on other binary packages of CUPS ONLY IF ABSOLUTELY NECESSARY! They must be installable on systems where the Debian's/Ubuntu's CUPS package is not installed, for example on systems which use the CUPS Snap or which use CUPS 3.x. @debiantriage please change the documentation about the printer-driver-.... packaging policy appropriately.

  • The situation with non-free drivers is basically no different from what it is now, just a single extra step. Install these drivers from the vendor and use the web interface of the Legacy Printer Application to set up a queue in the Application.

Yes, exactly this way.

zdohnal commented 1 year ago

Important note here for Debian packagers (@zdohnal): Please change ALL the printer-driver-... to NOT depend on cups-daemon any more and on other binary packages of CUPS ONLY IF ABSOLUTELY NECESSARY! They must be installable on systems where the Debian's/Ubuntu's CUPS package is not installed, for example on systems which use the CUPS Snap or which use CUPS 3.x. @debiantriage please change the documentation about the printer-driver-.... packaging policy appropriately.

Thank you for the reminder! I was about to do that once we have CUPS 3.x in Fedora, but I can make a change with SNAP in mind as well. However, I won't remove the dependency completely, I'll use a weak dependency for it to make a default installation functional and who will want to use SNAPs, he can remove the classic RPM.

The similar solution I will apply for printer apps as well - printer app will be a weak dependency of printer driver package, so user can remove the printer app RPM in case he wants to use classic drivers with CUPS 2.x or SNAPped printer app.

Just few tips from packaging: