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
155 stars 125 forks source link

can't use page-ranges option on remote printer #67

Closed archenemies closed 5 years ago

archenemies commented 5 years ago

I have the following printer configured on my desktop:

<Printer HP_Photosmart_Plus_B210_series>
UUID urn:uuid:f7c17874-8003-30ee-40b0-7f21f5f107c3
Info HP Photosmart Plus B210 series
MakeModel HP Photosmart Plus b210 Series, hpcups 3.18.6
DeviceURI usb://HP/Photosmart%20Plus%20B210%20series?serial=CN0AS2G4JJ05J9&interface=1
State Idle
StateTime 1539324752
ConfigTime 1536921968
Type 8425484
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-current-job
Option outputorder reverse
Attribute marker-colors none,none,none,none
Attribute marker-levels 69,56,57,54
Attribute marker-names black ink,yellow ink,cyan ink,magenta ink
Attribute marker-types ink,ink,ink,ink
Attribute marker-change-time 1506138993
</Printer>

I have it shared to my laptop with the following:

<Printer B210a_Remote>
UUID urn:uuid:424bc4eb-1711-38cd-4889-8957f6b53193
AuthInfoRequired none
Info HP Photosmart Plus B210 series
MakeModel Photosmart Plus b210 Series, hpcups 3.18.6
DeviceURI ipp://amenhotep/printers/HP_Photosmart_Plus_B210_series
State Idle
StateTime 1539324752
ConfigTime 1536905867
Reason cups-waiting-for-job-completed
Reason cups-remote-stopped
Type 4172
Accepting Yes
Shared No
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-current-job
Attribute marker-colors none,none,none,none
Attribute marker-levels 69,56,57,54
Attribute marker-names black ink,yellow ink,cyan ink,magenta ink
Attribute marker-types ink,ink,ink,ink
Attribute marker-change-time 1539324752
</Printer>

When I try to print a document using the 'page-ranges' option to select a page, I get an unhelpful "filter failed" error.

client$$ lp -o page-ranges=2 test.pdf
request id is B210a_Remote-1476 (1 file(s))

server$ sudo grep -n "Job 165" /var/log/cups/error_log -C10 > error.txt

Looks like the relevant lines are

48770:D [12/Oct/2018:06:29:41 +0000] [Job 165] PID 26869 (/usr/lib/cups/filter/gstoraster) exited with no errors.
48771:D [12/Oct/2018:06:29:41 +0000] [Job 165] prnt/hpcups/HPCupsFilter.cpp 567: cupsRasterOpen failed, fd = 0
48772:D [12/Oct/2018:06:29:41 +0000] [Job 165] PID 26870 (/usr/lib/cups/filter/hpcups) stopped with status 1.

Here is the full error.txt

archenemies commented 5 years ago

Here's another example, if I print the attached file in Okular or Evince, I select pages 2-3 and ask for 2 copies, I get 4 copies of pages 2 and 3.

If however I submit the job on the command line:

lp eprep-reqs.pdf -n 2 -o page-ranges=2-3

then I get 2 copies of just page 3. What could possibly be causing this behavior?

eprep-reqs.pdf

tillkamppeter commented 5 years ago

I have released cups-filters 1.21.4 now which contains fixes against duplicate execution of page management options. Also the newest CUPS (2.2.9) contains appropriate fixes. Can you please test with these version whether this also covers your issue?

archenemies commented 5 years ago

I'm guessing you want me to install these new versions on the server as well as the client?

archenemies commented 5 years ago

When building the package on the server, even after doing a full upgrade I get the following error:

  CC       foomatic_rip-util.o
filter/pdftoraster.cxx: In function ‘void outPage(PDFDoc*, Catalog*, int, SplashOutputDev*, cups_raster_t*)’:
filter/pdftoraster.cxx:1821:6: error: ‘gTrue’ was not declared in this scope
      gTrue,gTrue,gTrue);
      ^~~~~

So, I don't know what I'm missing. I get the same error when building the latest version of cups-filters from github, or when building a cups-filters package using an updated PKGBUILD from the Arch package.

Strangely the new package seems to have built and installed correctly on my laptop, but the bug persists.

If you provide me with some code to execute, then I can do it. Otherwise this may be over my head.

Anyway it's good to finally hear back that you've been working on this problem and that the cause is understood.

dheeraj135 commented 5 years ago

@archenemies This issue is same as #69. I think this issue can be closed now.

tillkamppeter commented 5 years ago

@dheeraj135, the compilation problem in the last comment of @archenemies, is issue #69, this issue is different and @archenemies needs to build the newest version to check whether it is already fixed. @archenemies, with your compilation problem please check the (already fixed) issue #69. Make sure you use the very newest cups-filters version.

tillkamppeter commented 5 years ago

@archenemies, did you any further testing with a new cups-filters version? I am closing this now as we did not get any further answer from you. Please re-open if you are still suffering the problem with the newest version of cups-filters. Thanks.

archenemies commented 5 years ago

I tried installing the newest cups-filters version on both devices. However, I'm still getting "filter failed" when I try to print something with both -n and -o page-ranges.

It might be nice to have a page with instructions that answer the following questions:

  1. how do I install the latest version of cups-filters

  2. How do I check that the latest version of cups-filters is installed

  3. How do I install the latest version of CUPS

  4. how do I check which CUPS version is installed

I think I can accomplish 1 and 3 very easily in this case since the version of CUPS in Arch Linux is 2.2.11 and you said 2.2.9 had the fixes. so I'll just upgrade Arch. However, when I want to install from Git, I'm not sure if I should use the PKGBUILD from the Arch package or if I should just run ./configure with no options. I'm attaching the Arch PKGBUILD. PKGBUILD.txt

Here is the result of a simple experiment:

# this prints one page
$ lp -dB210a_Remote -o page-ranges=1 moz.pdf
request id is B210a_Remote-2127 (1 file(s))
# this fails with "filter failed" in CUPS web GUI
$ lp -dB210a_Remote -n 2 -o page-ranges=3-4 moz.pdf
request id is B210a_Remote-2128 (1 file(s))

Here are the version numbers:

$ pacman -Qi cups | head -n 2
Name            : cups
Version         : 2.2.10-2
$ cups-browsed --version |& head -n 2
cups-browsed of cups-filters version 1.22.5
archenemies commented 5 years ago

Also, it seems like there is a clock issue.

And I didn't run into any build problems when building the latest cups-filters from Github.

tillkamppeter commented 5 years ago

You wrote:

$ pacman -Qi cups | head -n 2
Name            : cups
Version         : 2.2.10-2
$ cups-browsed --version |& head -n 2
cups-browsed of cups-filters version 1.22.5

CUPS 2.2.10 is a rather new version, 2.2.12 is the very newest, but I am not sure whether it would actually fix this bug. The version number of a running CUPS daemon you find also in the web interface http://localhost:631/. /var/log/cups/error_log probably contains it, too. cups-filters 1.22.5 is the currently released version. cups-browsed --version is one of the possible command to find out the version number of the installed cups-filters. driverless --version or foomatic-rip --version also works.

tillkamppeter commented 5 years ago

I do not know your PDF files. If I use a file with a sufficient number of pages, so that the page-ranges setting leaves at least one single page for me everything seems to work correctly. Can it be that your input files do not have enough pages letting pdftopdf output a zero-page file? Could you use the cupsfilter command of CUPS to test the filtering and then post the complete screen output of cupsfilter here? Please also attach the PDF files with which you obtain the "Filter failed". It seems that some filter (most probably hpcups) errors on zero-page or empty input. Filters receiving zero pages or empty input should output zero pages.

tillkamppeter commented 5 years ago

The error which you have in your error_log in the initial posting is the filter hpcups erroring on empty input. I have found it out by manually running the sequence of pdftopdf, gstoraster, and hpcups, with a one-page PDF as input and selecting pages 3 and 4 via page-ranges resulting in pdftopdf sending a zero-page PDF file to gastoraster and gstoraster producing no byte of output at all. hpcups does not error if actually receiving a zero-page Raster file, which would be a file only containing the "magic string" of Raster, "RaS2". So the fix would be checking all filters of cups-filters to output zero-page files instead of nothing if the output is zero pages. Reopening ...

archenemies commented 5 years ago

Thank you. I don't think it's a problem with zero pages but I'll have to get back when I have more time to investigate, maybe tomorrow I hope.

tillkamppeter commented 5 years ago

What do you mean with "Also, it seems like there is a clock issue"?

archenemies commented 5 years ago

What do you mean with "Also, it seems like there is a clock issue"?

Hmm, GitHub was telling me that one of your comments had been posted "3 hours from now". I don't know, were you using the email gateway and maybe there is a timezone issue? I'm sending this comment through email by the way, usually I use the website.

tillkamppeter commented 5 years ago

I do all my posts via the web interface. Perhaps you had the web site open for several hours. The pages do not auto-update, so you need to reload to see the correct relative time stamps.

archenemies commented 5 years ago

I do all my posts via the web interface. Perhaps you had the web site open for several hours. The pages do not auto-update, so you need to reload to see the correct relative time stamps.

That's interesting. I don't see how a future timestamp would result from an out-of-date web page, but I agree that, if you are using the web interface, it's hard to see how the problem could be on your end. My apologies.

archenemies commented 5 years ago

OK so cupsfilter seems like a useful command but when I try to use it, it just gives me an exact copy of the input document. This is using the PDF file I uploaded earlier:

$ foomatic-rip --version
foomatic-rip of cups-filters version 1.22.5
"man foomatic-rip" for help.
$ cupsfilter -n 2 -o page-ranges=3-4 eprep-reqs.pdf > t.pdf
DEBUG: argv[0]="cupsfilter"
DEBUG: argv[1]="1"
DEBUG: argv[2]="frederik"
DEBUG: argv[3]="eprep-reqs.pdf"
DEBUG: argv[4]="2"
DEBUG: argv[5]="page-ranges=3-4"
DEBUG: argv[6]="eprep-reqs.pdf"
DEBUG: envp[0]="<CFProcessPath>"
DEBUG: envp[1]="CONTENT_TYPE=application/pdf"
DEBUG: envp[2]="CUPS_DATADIR=/usr/share/cups"
DEBUG: envp[3]="CUPS_FONTPATH=/usr/share/cups/fonts"
DEBUG: envp[4]="CUPS_SERVERBIN=/usr/lib/cups"
DEBUG: envp[5]="CUPS_SERVERROOT=/etc/cups"
DEBUG: envp[6]="LANG=en_US.UTF8"
DEBUG: envp[7]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/bin:/bin:/usr/bin"
DEBUG: envp[8]="PPD=/usr/share/cups/model/laserjet.ppd"
DEBUG: envp[9]="PRINTER_INFO=cupsfilter"
DEBUG: envp[10]="PRINTER_LOCATION=Unknown"
DEBUG: envp[11]="PRINTER=cupsfilter"
DEBUG: envp[12]="RIP_MAX_CACHE=128m"
DEBUG: envp[13]="USER=frederik"
DEBUG: envp[14]="CHARSET=utf-8"
DEBUG: envp[15]="FINAL_CONTENT_TYPE=application/pdf"
INFO: gziptoany (PID 26202) started.
INFO: gziptoany (PID 26202) exited with no errors.
$ diff t.pdf eprep-reqs.pdf
$ # no differences

So here are some examples I did with paper:

# this prints 1 page, page 3
$ lp -dB210a_Remote -o page-ranges=2-3 eprep-reqs.pdf
request id is B210a_Remote-2140 (1 file(s))

# this prints 0 pages
$ lp -dB210a_Remote -o page-ranges=3-4 eprep-reqs.pdf
request id is B210a_Remote-2141 (1 file(s))

# this prints 2 pages, pages 3 and 4
$ lp -dB210a_Remote -o page-ranges=2-4 eprep-reqs.pdf
request id is B210a_Remote-2142 (1 file(s))

In all cases, the behavior is as if the page-ranges option is still getting applied twice. However, -n seems to only be applied once now, since when I do

$ lp -dB210a_Remote -o page-ranges=2-3 -n 2 eprep-reqs.pdf
request id is B210a_Remote-2143 (1 file(s))

then it produces 2 copies, and not 4.

Am I running the correct version of your software? Hope this helps.

tillkamppeter commented 5 years ago

You need to specify the output format in the cupsfilter command line. Otherwise PDF is assumed and with a PDF as input file no filtering will happen. Please check the man page of cupsfilter and specify as much as possible, for example also the PPD file of the printer for which you want to debug the filtering.

archenemies commented 5 years ago

OK sorry you'll need to tell me more information. I read the man page already. Can you provide an example command line for cupsfilter?

Also, maybe comment on the fact that it looks like page-ranges is still being applied twice? Did you fix that part of the bug; did you test your fixes? I'm not quite sure what additional data we're supposed to be learning from cupsfilter, beyond the information I already provided you in the previous comment.

tillkamppeter commented 5 years ago

Usually, you run the command this way:

cupsfilter -p <PPD file> -m application/vnd.cups-raster <input file> -o ... > <output file>

The <PPD file> is the name of the PPD file of your print queue. Note that it is only readable for root in its standard location in /etc/cups/ppd/. Use a copy at another place or run the command with sudo. The -m option specifies the output format, which one is the correct one you see in the PPD, in your case it is application/vnd.cups-raster. Start without page-ranges and check by the screen output which filters get called, then try also with page-ranges. Please post the screen output here. Also check with rasterview which pages make it into the output file.

tillkamppeter commented 5 years ago

The only way page-ranges can be applied twice is by the pdftopdf filter running on both client and server. Can you attach the PPD file which you are using on the client's print queue and the PPD file which you are using on the server's print queue? They are in /etc/cups/ppd/ on each machine, named with the print queue's name and the .ppd extension. To attach them here you have to add .txt to the end of the file name (like HP_Photosmart_Plus_B210_series.ppd.txt. Also check the /var/log/cups/error_log files on both client and server (in debug mode, run cupsctl --debug-logging to switch to debug mode) and attach the relevant parts here.

tillkamppeter commented 5 years ago

A way to get a correctly working client-side queue is not to create it manually but instead, let it get auto-created by cups-browsed (or by the client's CUPS). If you remove the queue on the client the auto-creation should take place.

archenemies commented 5 years ago

Thank you for your help. I am very busy this week but I will try your instructions when I have time.

archenemies commented 5 years ago

Sorry for the delay. Here are the PPDs:

B210a_Remote.ppd.txt HP_Photosmart_Plus_B210_series.ppd.txt

As you can see from the output of cupsfilter, both PPDs are processing the page-ranges option:

$ cupsfilter -p B210a_Remote.ppd -m application/vnd.cups-raster eprep-reqs.pdf -o page-ranges=2-3 > o_local.out
DEBUG: argv[0]="cupsfilter"                                                                                
DEBUG: argv[1]="1"
DEBUG: argv[2]="frederik"
DEBUG: argv[3]="eprep-reqs.pdf"
DEBUG: argv[4]="1"
DEBUG: argv[5]="page-ranges=2-3"
DEBUG: argv[6]="eprep-reqs.pdf"
DEBUG: envp[0]="<CFProcessPath>"
DEBUG: envp[1]="CONTENT_TYPE=application/pdf"
DEBUG: envp[2]="CUPS_DATADIR=/usr/share/cups"
DEBUG: envp[3]="CUPS_FONTPATH=/usr/share/cups/fonts"
DEBUG: envp[4]="CUPS_SERVERBIN=/usr/lib/cups"
DEBUG: envp[5]="CUPS_SERVERROOT=/etc/cups"
DEBUG: envp[6]="LANG=en_US.UTF8"
DEBUG: envp[7]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/bin:/bin:/usr/bin"
DEBUG: envp[8]="PPD=B210a_Remote.ppd"
DEBUG: envp[9]="PRINTER_INFO=cupsfilter"
DEBUG: envp[10]="PRINTER_LOCATION=Unknown"
DEBUG: envp[11]="PRINTER=cupsfilter"
DEBUG: envp[12]="RIP_MAX_CACHE=128m"
DEBUG: envp[13]="USER=frederik"
DEBUG: envp[14]="CHARSET=utf-8"
DEBUG: envp[15]="FINAL_CONTENT_TYPE=application/vnd.cups-raster"
INFO: pdftopdf (PID 32274) started.
INFO: gstoraster (PID 32275) started.
DEBUG: OUTFORMAT="(null)", so output format will be CUPS/PWG Raster
ERROR: pdftopdf: Last filter could not get determined, page logging turned off.
DEBUG: pdftopdf: Last filter determined by the PPD: None; FINAL_CONTENT_TYPE: application/vnd.cups-raster => pdftopdf will not log pages in page_log.
DEBUG: PDF interactive form and annotation flattening done via QPDF
DEBUG: Color Manager: Calibration Mode/Off
INFO: pdftopdf (PID 32274) exited with no errors.
DEBUG: Calling FindDeviceById(cups-cupsfilter)
DEBUG: Failed to send: org.freedesktop.ColorManager.NotFound:device id 'cups-cupsfilter' does not exist
DEBUG: Failed to get find device cups-cupsfilter
DEBUG: Calling FindDeviceById(cups-cupsfilter)
DEBUG: Failed to send: org.freedesktop.ColorManager.NotFound:device id 'cups-cupsfilter' does not exist
DEBUG: Failed to get device cups-cupsfilter
INFO: Color Manager: no profiles specified in PPD
DEBUG: Color Manager: ICC Profile: None
DEBUG: Ghostscript using Any-Part-of-Pixel method to fill paths.
DEBUG: Ghostscript command line: gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -sMediaType=Stationery -r300x300 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=19 -scupsPageSizeName=Letter -I/usr/share/cups/fonts -c '<</.HWMargins[9.014174 42.179527 9.014160 9.014160] /Margins[0 0]>>setpagedevice' -f -_
DEBUG: envp[0]="<CFProcessPath>"
DEBUG: envp[1]="CONTENT_TYPE=application/pdf"
DEBUG: envp[2]="CUPS_DATADIR=/usr/share/cups"
DEBUG: envp[3]="CUPS_FONTPATH=/usr/share/cups/fonts"
DEBUG: envp[4]="CUPS_SERVERBIN=/usr/lib/cups"
DEBUG: envp[5]="CUPS_SERVERROOT=/etc/cups"
DEBUG: envp[6]="LANG=en_US.UTF8"
DEBUG: envp[7]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/bin:/bin:/usr/bin"
DEBUG: envp[8]="PPD=B210a_Remote.ppd"
DEBUG: envp[9]="PRINTER_INFO=cupsfilter"
DEBUG: envp[10]="PRINTER_LOCATION=Unknown"
DEBUG: envp[11]="PRINTER=cupsfilter"
DEBUG: envp[12]="RIP_MAX_CACHE=128m"
DEBUG: envp[13]="USER=frederik"
DEBUG: envp[14]="CHARSET=utf-8"
DEBUG: envp[15]="FINAL_CONTENT_TYPE=application/vnd.cups-raster"
INFO: Start rendering...
INFO: Processing page 1...
INFO: Processing page 2...
INFO: Processing page 3...
INFO: Rendering completed
INFO: gstoraster (PID 32275) exited with no errors.

$ cupsfilter -p HP_Photosmart_Plus_B210_series.ppd -m application/vnd.cups-raster eprep-reqs.pdf -o page-ranges=2-3 > o_remote.out
DEBUG: argv[0]="cupsfilter"
DEBUG: argv[1]="1"
DEBUG: argv[2]="frederik"
DEBUG: argv[3]="eprep-reqs.pdf"
DEBUG: argv[4]="1"
DEBUG: argv[5]="page-ranges=2-3"
DEBUG: argv[6]="eprep-reqs.pdf"
DEBUG: envp[0]="<CFProcessPath>"
DEBUG: envp[1]="CONTENT_TYPE=application/pdf"
DEBUG: envp[2]="CUPS_DATADIR=/usr/share/cups"
DEBUG: envp[3]="CUPS_FONTPATH=/usr/share/cups/fonts"
DEBUG: envp[4]="CUPS_SERVERBIN=/usr/lib/cups"
DEBUG: envp[5]="CUPS_SERVERROOT=/etc/cups"
DEBUG: envp[6]="LANG=en_US.UTF8"
DEBUG: envp[7]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/bin:/bin:/usr/bin"
DEBUG: envp[8]="PPD=HP_Photosmart_Plus_B210_series.ppd"
DEBUG: envp[9]="PRINTER_INFO=cupsfilter"
DEBUG: envp[10]="PRINTER_LOCATION=Unknown"
DEBUG: envp[11]="PRINTER=cupsfilter"
DEBUG: envp[12]="RIP_MAX_CACHE=128m"
DEBUG: envp[13]="USER=frederik"
DEBUG: envp[14]="CHARSET=utf-8"
DEBUG: envp[15]="FINAL_CONTENT_TYPE=application/vnd.cups-raster"
INFO: pdftopdf (PID 31769) started.
INFO: gstoraster (PID 31770) started.
DEBUG: OUTFORMAT="(null)", so output format will be CUPS/PWG Raster
DEBUG: pdftopdf: Last filter determined by the PPD: hpcups; FINAL_CONTENT_TYPE: application/vnd.cups-raster => pdftopdf will not log pages in page_log.
DEBUG: PDF interactive form and annotation flattening done via QPDF
DEBUG: Color Manager: Calibration Mode/Off
INFO: pdftopdf (PID 31769) exited with no errors.
DEBUG: Calling FindDeviceById(cups-cupsfilter)
DEBUG: Failed to send: org.freedesktop.ColorManager.NotFound:device id 'cups-cupsfilter' does not exist
DEBUG: Failed to get find device cups-cupsfilter
DEBUG: Calling FindDeviceById(cups-cupsfilter)
DEBUG: Failed to send: org.freedesktop.ColorManager.NotFound:device id 'cups-cupsfilter' does not exist
DEBUG: Failed to get device cups-cupsfilter
INFO: Color Manager: no profiles specified in PPD
DEBUG: Color Manager: ICC Profile: None
DEBUG: Ghostscript using Any-Part-of-Pixel method to fill paths.
DEBUG: Ghostscript command line: gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -sMediaType=Plain -sOutputType=0 -r600x600 -dMediaPosition=7 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=17 -dcupsInteger0=2 -scupsPageSizeName=Letter -I/usr/share/cups/fonts -c '<</.HWMargins[9.000000 9.000000 9.000000 9.000000] /Margins[0 0]>>setpagedevice' -f -_
DEBUG: envp[0]="<CFProcessPath>"
DEBUG: envp[1]="CONTENT_TYPE=application/pdf"
DEBUG: envp[2]="CUPS_DATADIR=/usr/share/cups"
DEBUG: envp[3]="CUPS_FONTPATH=/usr/share/cups/fonts"
DEBUG: envp[4]="CUPS_SERVERBIN=/usr/lib/cups"
DEBUG: envp[5]="CUPS_SERVERROOT=/etc/cups"
DEBUG: envp[6]="LANG=en_US.UTF8"
DEBUG: envp[7]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/bin:/bin:/usr/bin"
DEBUG: envp[8]="PPD=HP_Photosmart_Plus_B210_series.ppd"
DEBUG: envp[9]="PRINTER_INFO=cupsfilter"
DEBUG: envp[10]="PRINTER_LOCATION=Unknown"
DEBUG: envp[11]="PRINTER=cupsfilter"
DEBUG: envp[12]="RIP_MAX_CACHE=128m"
DEBUG: envp[13]="USER=frederik"
DEBUG: envp[14]="CHARSET=utf-8"
DEBUG: envp[15]="FINAL_CONTENT_TYPE=application/vnd.cups-raster"
INFO: Start rendering...
INFO: Processing page 1...
INFO: Processing page 2...
INFO: Processing page 3...
INFO: Rendering completed
INFO: gstoraster (PID 31770) exited with no errors.

Using rasterview I can see that both output files contain two pages, corresponding to page 2 and 3 of the original document.

I'm not sure but I believe I created the local queue this way:

lpadmin -p B210a_Remote -m everywhere -E -v ipp://amenhotep/printers/HP_Photosmart_Plus_B210_series

It was hard to discover the above command because the CUPS documentation preferred way of creating the queue assumes that I have a working Avahi/mDNS/Bonjour/whatever-it-is-called, which I do not.

$ ping amenhotep.local
ping: amenhotep.local: Name or service not known
[2]$

Is this enough information for you to proceed or do you still need /var/log/cups/error_log? (I would not run cupsctl as you suggested, because I think it deletes all the comments in /etc/cups/cupsd.conf is this correct?)

tillkamppeter commented 5 years ago

Thank you for the information. You do not need to use cupsctl for switching to debug logging. To set the log level to debugging mode you simply stop CUPS, edit /etc/cups/cupsd.conf editing the LogLevel line to be LogLevel debug or create such a line if there is none. Then start CUPS again. The problem is that both on your server and on your client you have CUPS queues with PPD files. This means filters are run on both client and server, especially also the pdftopdf filter which processes the page-ranges option. This makes the option to be applied twice, and so selecting page 3 and 4 lets the client pass on a file with 2 pages, page 3 and 4 of the original document and the server receives this 2-page document and tries to select the 3rd and the 4th page of it, ending up with no page at all. CUPS and cups-filters have added a fix to their PPD generators to avoid duplicate execution of pdftopdf on client and server. I do not remember which version, so it would be of help if you could tell for both client and server, which versions of CUPS and cups-filters you have installed. For the time being please try to create a raw queue on the client, using the command

lpadmin -p B210a_Remote -m raw -E -v ipp://amenhotep/printers/HP_Photosmart_Plus_B210_series

Does the queue work correctly this way?

tillkamppeter commented 5 years ago

I have checked your client's PPD file and it contains the line

*cupsFilter2: "application/vnd.cups-pdf application/pdf 10 -"

This you would get when creating a queue pointing to a remote CUPS printer with CUPS 2.2.8 or older on the client and it leads to duplicate execution of pdftopdf (on both client and server). In CUPS 2.2.9 CUPS issue #5361 got fixed and you would get

*cupsFilter2: "application/pdf application/pdf 10 -"

in your PPD which prevents the execution of pdftopdf on the client. Make sure you have updated your CUPS to this version on both server and client. I also highly recommend to update cups-filters to at least version 1.21.0 to avoid the same bug with PPDs generated by cups-browsed.

tillkamppeter commented 5 years ago

If you get the wrong `*cupsFilter2: ..." line in your PPD with CUPS 2.2.9 or newer on your client using your command line

lpadmin -p B210a_Remote -m everywhere -E -v ipp://amenhotep/printers/HP_Photosmart_Plus_B210_series

please report an issue on CUPS.

archenemies commented 5 years ago

(it says "Email replies do not support Markdown", so I'm posting this again via the web interface)

Thank you for the attention. Here is what I get when running that command:

$ lpadmin -p B210a_Remote -m raw -E -v ipp://amenhotep/printers/HP_Photosmart_Plus_B210_series   
lpadmin: Raw queues are deprecated and will stop working in a future version of CUPS.
lpadmin: Use the 'everywhere' model for shared printers.
$ sudo lpadmin -p B210a_Remote -m raw -E -v ipp://amenhotep/printers/HP_Photosmart_Plus_B210_series 
lpadmin: Raw queues are deprecated and will stop working in a future version of CUPS.
lpadmin: Use the 'everywhere' model for shared printers.

I don't know what an "'everywhere' model" or a "raw queue" is, but seems to have caused the following change in /etc/cups/ppd/B210a_Remote.ppd:

< *cupsFilter2: "application/vnd.cups-pdf application/pdf 10 -"
---
> *cupsFilter2: "application/pdf application/pdf 0 -"

Was that the whole problem?

Anyway, here are the versions on the client:

$ pacman -Qi cups | head -n 2; cups-browsed --version |& head -n 2   
Name            : cups
Version         : 2.2.10-2
cups-browsed of cups-filters version 1.22.5

and the server:

$ pacman -Qi cups | head -n 2; cups-browsed --version |& head -n 2
Name            : cups
Version         : 2.2.11-2
cups-browsed of cups-filters version 1.22.5

Now when I run

$ lp -dB210a_Remote -o page-ranges=2-3 -n 2 eprep-reqs.pdf
request id is B210a_Remote-2207 (1 file(s))

I get two copies of page 2 followed by two copies of page 3. In other words I got "page 2, page 2, page 3, page 3" where I had expected "page 2, page 3, page 2, page 3". I guess that's better than just two copies of page 3, which it had been doing before...

tillkamppeter commented 5 years ago

Add "-o collate":

$ lp -dB210a_Remote -o page-ranges=2-3 -o collate -n 2 eprep-reqs.pdf

Do the pages come out in the desired order now?

About raw queues and "everywhere" model: A raw queue ("-m raw") is a print queue without PPD (or driver) at all, job data is passed on completely unfiltered to the destination. This was formerly used to pass on jobs to remote CUPS queues as the server's CUPS is doing the filtering. This still works with current CUPS, "deprecated" is not "removed". It is supposed to be removed in a future version of CUPS. The "everywhere model" means a print queue with the model selection "everywhere" ("-m everywhere"). This model setting is for driverless IPP printers. The printer is queried for its capabilities and based on this the PPD file for the local print queue is auto-generated. "Driverless" means here that no software/filter/PPD file specific to the printer needs to be supplied by the user, CUPS and cups-filters provide everything for the printer to work. As CUPS is fully IPP-based every shared CUPS queue (like the one on your server) is emulating a driverless IPP printer and therefore you can set up the queue on the client this way. The term "everywhere" comes from "IPP Everywhere", the fully open driverless IPP printing standard of the Printer Working Group (PWG), but CUPS and cups-filters also support the other driverless IPP printing standards (AirPrint, Mopria, Wi-Fi Direct Print) as they work practically the same way.

tillkamppeter commented 5 years ago

The bug reported here is actually the CUPS issue #5361 which is fixed in CUPS 2.2.9 and cups-filters 1.21.0. Closing as it is already fixed. @archenemies, but still tell whether "-o collate" gives you the desired result. Thanks.

archenemies commented 5 years ago

Thank you for defining the terms "raw queues" and "everywhere model".

If I pass -o collate then the output is collated. It seems strange that collation is not the default (should I set it as a default with lpoptions?). But indeed it is unrelated to the queue being remote, since I get the same page ordering (2,2,3,3) when I copy the document to the server and print it directly:

$ lp -dHP_Photosmart_Plus_B210_series -o page-ranges=2-3 -n 2 eprep-reqs.pdf
request id is HP_Photosmart_Plus_B210_series-914 (1 file(s))

So it seems good to close the issue. Thank you again.