Epson L8180/ET-8550: flawed PWG-raster implementation. AppleRaster is prefered.

[kanyck]

Hello,
I am an owner of Epson L8180 (=ET8550) printer. I've tried to connect to it with several different ways (escpr2, IPP Everywhere, driverless) and got nothing close to what this model supports under Mac concerning print dialog options. As I can see from running
ipptool -tv ipps://EPSON0B79A1.lan:631/ get-printer-attributes.test the printer supports limited subset in pwg-raster in comparison with AppleRaster but cups sends pwg-raster to it, limiting the options even further. Whats's even worse, I apparently have little control even upon the image size. It actually prints smaller images even with Scale set to none (printing from GIMP @ 360dpi). My question is what I can do about it (besided bying a Mac) to get it close to the full power, or, at least make it print the right size. Thanks beforehand!

printercaps.txt
ppd's extracted from Epson's .dmg for Mac (languages stripped) and generated by cups-filters in driverless mode.
EpsonMAC.ppd.txt
EpsonDriverless.ppd.txt

[tillkamppeter]

This is not a bug, but more about discussing how printer drivers work. Please enter here:

OpenPrinting/cups-sharing#4

[kanyck]

@tillkamppeter Don't be that snobby.

This is not a bug

Of course it is! When I export an image from Darktable sized 452x300mm @360dpi, print it with GIMP that also shows 452x300mm and finally apply a ruler to the printout and see 445x295mm it is a bug! When I change Scaling from None to Fill and nothing changes, it is a bug. When I request centered printing and see the printed image off center about 3mm, it also is a bug. When you give no other choice but relying on buggy half-backed printer firmware to make your life easier, it is worse than a bug! Can you distinguish printing a label from printing a photograph? If anything is coming out of printer, this doesn't imply that everything is 'perfect'.

When you stating in your fancy shining blog without any reservations that

Most modern printers <...> do driverless IPP printing, most commonly AirPrint but currently also Mopria. So they work perfectly under Linux and alike operating systems

you misinform your readers, because it's obviously not true. Don't believe me? Visit, say, https://discuss.pixls.us/ then search for 'printing' and see what people say. That won't take much time, there's only few such threads there. The consensual opinion is that photo printing from under Linux is much closer to 'total disaster' state but far from being 'perfect' as you stated. If you would say "We concentrate our efforts on label printing, POSes and corporate printing needs because that's where the money is, and if you want photo printing under Linux, you're on your own", that would be at least the honest position. When you say it's 'perfect' without any reservation, you just lie to us. Sorry.

[tillkamppeter]

Sorry, seems that I have put this message onto the wrong issue. I am not able to reproduce its reasoning. I will look into the issue.

[tillkamppeter]

Could you switch to debug logging via

    cupsctl --debug-logging

and then print a job where the problem occurs. After that attach the file /var/log/cups/error_log to this bug report.

Note that you have to rename the copy you attach to have a name ending with .txt so that GitHub accepts it.

[kanyck]

Here you go...
error_log.txt
Thanks!

[tillkamppeter]

Thanks, but, unfortunately, your error_log was a miss. It seemsed to have shaved some logging from the end of the job processing but did not catch the beginning. Probably you have some strict limit on log file size somewhere, so that only a small part of the job's logging fits.

Could you check your /etc/cups/error_log, look for lines starting with MaxLog, remove them and add the line

MaxLogSize 0

Now restart CUPS (or reboot) to get your changes active.
This done, could you print another job and attach /var/log/cups/error_log again? Thanks.

[tillkamppeter]

Let us also try to find out whether simply switching from PWG Raster output to Apple Raster output would solve your problem.

Could you stop CUPS via

sudo systenctl stop cups

then edit your PPD file /etc/cups/ppd/QUEUE.ppd (with QUEUE being the name of your print queue) changing the line

*cupsFilter2: "image/pwg-raster image/pwg-raster 10 -"

to

*%cupsFilter2: "image/pwg-raster image/pwg-raster 10 -"

The added % after the * in the beginning makes a comment line out of the line, making it inactive. This makes CUPS not trying to send PWG Raster to your printer any more but the alternative URF (Apple Raster) format.

Save the modified PPD file and start CUPS again:

sudo systenctl start cups

Try to print. Is the output the correct size now?

It seems that if your printer receives PWG Raster, it tries to scale the pages down into the frame defined by the printer's unprintable margins, making them slightly smaller.

[kanyck]

It seems that if your printer receives PWG Raster, it tries to scale the pages down into the frame defined by the printer's unprintable margins, making them slightly smaller.

Unfortunately not. I already discounted real paper size (=set as Custom size 1) by 3+3mm each direction and adjusted the real picture size accordingly. Also, when I print PWG-raster @ A4 borderless, the printer by itself scales the picture in the other direction, making it larger and cutting some valid areas out (about probably 2-3mm). So I may conclude that PWG-raster is included by Epson just to have the box checked and is practically unusable in this model. What a shame!

However, when I disabled PWG-raster according to your suggestions, it printed just the right sized image via AppleRaster! I did not checked it yet, but maybe it will be able to print AppleRaster @720dpi, too. I did not checked if Scale works now either (I believe it is). So technically the issue is solved in this part and you may close it if you have nothing to add.

I also think it may be helpful to provide some mechanism to disable the buggy implementation(s) other than editing the .ppd file by hand. (No problem with myself, but it seems to be quite unreliable solution generally). As a side note, it also would be nice to have the opportunity to add custom ICC profiles. At the moment I have not found any possibility to do that. Probably, they ought to be registered via colord to show up?

And I'm adding a log file JFYI. Thanks!
error_log.txt

[kanyck]

It also seems that in PWG raster mode, besides the size issues, it prints darker than it should. TBH I don't feel like waste more paper&ink to print side by side to make sure it is so, yet I'm pretty sure it is. Maybe this info will be helpful to someone...

[tillkamppeter]

Some remarks:

The stretching of the page by some mm when printing borderless is for the so-called overspray. The printer prints a page slightly larger than the paper to assure that the paper is really fully covered, even with slight tolerances in paper traction. The upcoming IPP Everywhere 2.0 will add an attribute for the user to be able to control overspray, the size of the actual print area, whether the image should be stretched or the pixels of the border row be repeated, or overspray turned off at all (for size fidelity).

Good news that at least Apple Raster works! I have already observed PWG-Raster bugs on other printers and in cups-filters I prefer Apple Raster therefore. You could try to create a print queue based on the PPD file generator of cups-filters.

Run the command (the driverless: + URI triggers the PPD file generator of cups-filters):

    lpadmin -p testipp -E -v ipps://EPSON0B79A1.lan:631/ipp/print -m driverless:ipps://EPSON0B79A1.lan:631/ipp/print -o PageSize=A4

Test this queue by the following 2 commands:

    lp -d testipp file.pdf
    lp -d testipp -o print-scaling=none file.pdf

Independent whether you get a correct or wrong printout, please attach the error_log and /etc/cups/ppd/testipp.ppd.

The queue is permanent, you only need to create it once, like a classic print queue with a driver. Ignore the warning that drivers are deprecated. The driverless utility is a retro-fit to allow classic printer setup tools create print queues for driverless printers. driverless emulates a driver for CUPS but internally polls the printer's capabilies from the printer via IPP and based on that generates the PPD file.

@michaelrsweet should we make CUPS' PPD generator also prefer Apple Raster against PWG Raster? For example by using a cost value of 100 instead of 10 in *cupsFilter2: ... line for PWG Raster in the generated PPD?

ICC profiles are currently registered with colord, but there was already discussion that colord will get discontinued sooner or later. See also this thread on our mailing list.

[kanyck]

Do I understand you correctly that I shall do these tests in PWG raster mode?
(Also, I'm far from being a printing guru, but I do strongly believe that my printer is not an exception and Apple Raster is much less buggy in average firmware than PWG raster is, because the Apple devices are much more widespread than Linux boxes and therefore gain more manufacturer's attention. I was very disappointed with my printer's operation and TBH even started to set qemu up to fire up Windows as a print server. And I'll be happy to avoid this!)
Thanks for colord info. I will look into it definitely, I could not find much of info on this.

[tillkamppeter]

Sorry, there is something wrong, hold on with the test of my last comment (lpadmin ...) I need to check something there ...

[kanyck]

No problem, I'll do this tomorrow anyway.

[tillkamppeter]

Now I have found out: Your old PPD is from cups-filters (1.x) not CUPS, and I have the checked the source code. cups-filters 1.x does actually wrong (cost value for PWG Raster must be higher to make Apple Raster actually preferred, see below, test (1), or PWG Raster support removed when Apple Raster is supported, as CUPS) while cups-filters 2.x and CUPS do both right (both only include a line for PWG Raster in the PPD if the printer does not support Apple Raster, test (2) below).

So I will ask you for two tests:

1. Try to fix cups-filters 1.x

Could you stop CUPS via

sudo systenctl stop cups

then edit your PPD file /etc/cups/ppd/QUEUE.ppd (with QUEUE being the name of your print queue) changing the line

*cupsFilter2: "image/pwg-raster image/pwg-raster 10 -"

to

*cupsFilter2: "image/pwg-raster image/pwg-raster 50 -"

The number is the so-called cost value. CUPS selects filter chains by the sum of cost values. Raising a cost value makes a filter chain less likely to be used. Try also 100 (or even higher) if this test fails.

Save the modified PPD file and start CUPS again:

sudo systenctl start cups

Try to print. Is the output the correct size now?

To save ink, I recommend you to create a file with a simple black drawing, or try to print the sample PDF file of this (similar symptoms) bug report: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1998917

2. Does CUPS right?

Run the command (the -m everywhere triggers the PPD file generator of CUPS, same as auto-generated temporary queue of CUPS):

    lpadmin -p testipp2 -E -v ipps://EPSON0B79A1.lan:631/ipp/print -m everywhere -o PageSize=A4

Test this queue by the following 2 commands:

    lp -d testipp2 file.pdf
    lp -d testipp2 -o print-scaling=none file.pdf

Independent whether you get a correct or wrong printout, please attach the error_log and /etc/cups/ppd/testipp.ppd.

The queue is permanent, you only need to create it once, like a classic print queue with a driver.

[kanyck]

Here you go...
1.1 Driverless unmodified
lp -d EpsonDriverless Downloads/170x230.pdf -> "page borders overlap" error
the same file printed via lpgtk with A4 Borderless set gives 174.5x236 instead of 170x230
lp -d EpsonDriverless -o media=iso_a4_210x297mm Downloads/170x230+.pdf (modified file with additional rectanlge with 3mm margin from the page edges) -> 174.5x236, external rectanlge off page
lp -d EpsonDriverless -o media=iso_a4_210x297mm -o print-scaling=none Downloads/170x230+.pdf -> 174.5x236, external rectanlge off page
1.2 Cost value 50
lp -d EpsonDriverless -o media=iso_a4_210x297mm -o print-scaling=none Downloads/170x230+.pdf ->
174.5x236, external rectanlge off page
1.3 Cost value 100
lp -d EpsonDriverless -o media=iso_a4_210x297mm -o print-scaling=none Downloads/170x230+.pdf -> 174.5x236, external rectanlge off page
1.3 Cost value 500
lp -d EpsonDriverless -o media=iso_a4_210x297mm -o print-scaling=none Downloads/170x230+.pdf -> 174.5x236, external rectanlge off page
1.4 PWG raster disabled
lp -d EpsonDriverless -o media=iso_a4_210x297mm -o print-scaling=none Downloads/170x230+.pdf -> still 174.5x236, external rectanlge off page
2. IPP Everywhere
lp -d testipp2 -o media=iso_a4_210x297mm -o print-scaling=none Downloads/170x230+.pdf -> 170x230, outer rectangle in place
lp -d testipp2 -o media=iso_a4_210x297mm Downloads/170x230+.pdf -> 170x230, outer rectangle in place

That seems to be all...

Files:
(just for a case)
170x230+.pdf
error_log.txt

UPD: in IPP Everywhere mode the Scaling option is missing in print dialog

[tillkamppeter]

Could you repeat test (1) but with a freshly created print queue, via

lpadmin -p testipp3 -E -v ipps://EPSON0B79A1.lan:631/ipp/print -m driverless:ipps://EPSON0B79A1.lan:631/ipp/print -o PageSize=A4

Go through the cost values again and see when it works.

[kanyck]

lp -d testipp3 -o media=iso_a4_210x297mm -o print-scaling=none Downloads/170x230+.pdf -> smaller, 165x224, double-wide borders
lp -d testipp3 -o media=iso_a4_210x297mm Downloads/170x230+.pdf -> the same
Cost 50:
lp -d testipp3 -o media=iso_a4_210x297mm -o print-scaling=none Downloads/170x230+.pdf -> the same
Cost 100:
lp -d testipp3 -o media=iso_a4_210x297mm -o print-scaling=none Downloads/170x230+.pdf -> OK!
error_log.txt

[kanyck]

BTW, looking through the printer attirbutes IPP response I saw
document-format-preferred (mimeMediaType) = image/urf
Looks like cups doesn't make use of this line...

[tillkamppeter]

Thanks a lot, @kanyck. So all is what I expected. By the cost values one can make CUPS selecting the Apple Raster path. But as CUPS itself does not even put the PWG Raster line into the PPD file when Apple Raster is supported, I will follow in cups-filters 1.x and do the same. In cups-filters 2.x (libppd) I do this already by only putting one *cupsFilter2: ... line into the PPD file.

[kanyck]

I'm glad being helpful. So, finally, what would you suggest me for now to get the most of my kludgy Epson? Use driverless with commented out PWG raster? And, from what I read from links you provided, if I want to print with ICC profiles, I need either manually convert the image in GIMP before printing or fire up the qemu/Win/Epson print app combo. The colord stuff is still unclear for me at the moment, but I think I can use it as semi-automated way to apply profiles instead doing it manually in GIMP. Disappointing... (Side note on printer profiles. Regular practice for (semi)professional printing is making custom profiles for printer/ink/paper combo. Serious paper manufacturers provide such profiles on their web sites, and for photo printing it's very important to support them somehow. I don't think this thread is the right place for this discussion, being off-topic, so I stop right here). Thanks for the links!

[tillkamppeter]

Fixed in cups-filters 1.x with commit 05f7344

Here we create only one *cupsFilter2: ... line for raster output in the PPD, for the most desirable/reliable format. Priority order is: Apple Raster, PWG Raster, PCLm.

In cups-filters 2.x (libppd) and CUPS this is already solved, the same way.

[tillkamppeter]

BTW, looking through the printer attirbutes IPP response I saw
document-format-preferred (mimeMediaType) = image/urf
Looks like cups doesn't make use of this line...

@michaelrsweet how reliable is document-format-preferred? should we use this or simply use the priority order I used in my fix?