When I print an A4 PDF-Document on an A4 page, the result is an A5 content on an A4 page. When I print an A4 PDF-Document on an A3 page, the result is an A4 content on an A3 page. Version of Okular: 1.0.3, KDE Frameworks 5.42.0, Qt 5.9.2, on Fedora 26 Version of Cups: 2.2.2-8 Reproducible: Always Steps to Reproduce: 1. Open Okular 2. Open an A4 PDF-Document of your coice. 3. Open Print dialog 4. Select A4 if not already selected 5. Select print Actual Results: Output is A5 on A4 page Expected Results: Output should be A4 on A4 page
Please try again with a newer version of Okular; Fedora 27 provides 1.3.1.
I tried it on Fedora 27 with Okular 1.2.1 and with the latest version 1.3.1. It doesn't help. Same result.
I cannot reproduce the problem here. Does it happen for every document you use? Can you attach one that is affected. Does it happen when you choose "Print to File (PDF)" instead of a real printer? In addition, it may be helpful to see what the CUPS log says. Can you do the following: * increase CUPS's log level by changing the "LogLevel" directive in /etc/cups/cupsd.conf to "LogLevel debug" * restart CUPS by running "sudo systemctl restart cups.service" * try to print an A4 PDF document on an A4 page from Okular * have a look and attach the CUPS log file /var/log/cups/error_log here
(In reply to Michael Weghorn from comment #3) > I cannot reproduce the problem here. I can always reproduce it. > > Does it happen for every document you use? Can you attach one that is > affected. Yes for every document. Will attach one. > > Does it happen when you choose "Print to File (PDF)" instead of a real > printer? No, that's OK. > > In addition, it may be helpful to see what the CUPS log says. Can you do the > following: > * increase CUPS's log level by changing the "LogLevel" directive in > /etc/cups/cupsd.conf to "LogLevel debug" > * restart CUPS by running "sudo systemctl restart cups.service" > * try to print an A4 PDF document on an A4 page from Okular > * have a look and attach the CUPS log file /var/log/cups/error_log here LogLevel is set to debug. Did a restart. No logfile is written. Maybe a new bug. I wish I could send you the error_log.
Created attachment 110395 [details] Example to print
(In reply to Attila from comment #4) > LogLevel is set to debug. Did a restart. No logfile is written. Maybe a new > bug. I wish I could send you the error_log. That's interesting... Does this mean the file /var/log/error_log does not exist at all? What is the exact "ErrorLog" directive in "/etc/cups/cups-files.conf"? That one specifies where the log output is written to. (It would be "ErrorLog /var/log/cups/error_log" if that is the file to write to, but can also be sth like "syslog", in which case the output needs to be retrieved another way...). What is the output of the command "sudo systemctl status cups.service"?
The ErrorLog directive was syslog. You can check now the attached files error_log and the output of systemctl status cups.service
Created attachment 110402 [details] error_log
Created attachment 110403 [details] Output of systemctl status cups.service
(In reply to Attila from comment #7) > You can check now the attached files error_log and the output of systemctl > status cups.service Thanks! At first glance, I don't see anything obvious. What is interesting here is that no "real" CUPS filters are processed, as the printer seems to support "application/postscript". Can you please also attach the PPD file for your printer? It should be located at /etc/cups/ppd/HPM880.ppd What would also be interesting is the print file generated by Okular. You can for example get it as follows: * stop the printer, command: "sudo cupsdisable HPM880" * start print job from Okular as before The file should then then be located under "/var/spool/cups/d<JOB_ID>-001" (where "<JOB_ID>" needs to be replaced by the ID for the CUPS print job. Can you please attach that file here as well? (Then you can start the printer again (command "sudo cupsenable HPM880" and the printout should take place.)
Just two things to mention: - This "bug" is not only related to the printer HPM880. I get the same result on different printers. - The printer is served by a Cups server. Is that the reason, why you said no "real" CUPS filters are processed?
Created attachment 110405 [details] File generated by Okular
Created attachment 110406 [details] PPD file HPM880
Thanks for the additional information. (In reply to Attila from comment #11) > - The printer is served by a Cups server. Is that the reason, why you said > no "real" CUPS filters are processed? Probably yes. I didn't know about your setup, but the error_log shows what filters are processed. In case the printer is served by another CUPS server, filtering should be done there, not locally, so this makes sense. I suppose that the information that the printers are served by a CUPS server on another machine is relevant for the problem. (The files I saw so far from the local machine look "reasonable" to me at first sight.) Do you by any chance have the possibility to do a printout on a printer that is directly connected to the computer on which Okular is running? Also, getting the CUPS error_log (with debugging enabled) and the PPD of the printer from the machine where the CUPS server is running will probably be of help to further analyse the issue. What kind of operating system is that machine running and what version of CUPS is in use there?
(In reply to Michael Weghorn from comment #14) > Thanks for the additional information. > > (In reply to Attila from comment #11) > > - The printer is served by a Cups server. Is that the reason, why you said > > no "real" CUPS filters are processed? > > I suppose that the information that the printers are served by a CUPS server > on another machine is relevant for the problem. (The files I saw so far from > the local machine look "reasonable" to me at first sight.) > > Also, getting the CUPS error_log (with debugging enabled) and the PPD of the > printer from the machine where the CUPS server is running will probably be > of help to further analyse the issue. What kind of operating system is that > machine running and what version of CUPS is in use there? Here the error_log, print file and PPD as requested. These files are all from the Cups server.
Created attachment 110424 [details] error_log from cups server
Created attachment 110425 [details] PPD file HPM880 from Cups server
Created attachment 110426 [details] File generated by Okular from Cups server
(In reply to Attila from comment #15) > [...] > Here the error_log, print file and PPD as requested. These files are all > from the Cups server. Thanks. I still don't see anything obvious. The file generated by Okular on the one host is identical to the one on the CUPS server host (which is expected). For simplification, I suggest to use the following names for the two hosts involved for now: * Host A: Computer where Okular is running * Host B: Computer where the CUPS server is running that the print jobs are sent to Can you try the following: 1) print the PDF file from another application on host A, e.g. from Evince and from the command line using the following command: lp -d HPM880 -o PageSize=A4 <PDF_FILE> 2) print the PDF file directly on host B using the command line: lp -d HPM880 -o PageSize=A4 <PDF_FILE> 3) print the file generated by Okular directly via the command line on host B (<PS_FILE> is https://bugs.kde.org/attachment.cgi?id=110406): lp -d HPM880 -o PageSize=A4 <PS_FILE> 4) print the PDF file from Okular on host A with "Force rasterisation" enabled in the print dialog under "Options" -> "PDF Options" 5) set up a dummy printer on host B that saves the file that would normally be sent to the printer into a file instead. On host B, do: * enable file devices by setting the directive "FileDevice Yes" in /etc/cups/cups-files.conf * restart CUPS * set up the printer with the same PPD file as the printer used previously by running this command: "sudo lpadmin -p tofile-test -v file:/tmp/tofile-test -P /etc/cups/ppd/HPM880.ppd" * make the printer available to the client as well And then "print" to this printer. A file should be created under /tmp/tofile-test on host B. Can you attach this one here? (Depending on the system, you might have to use the option "-v file:$HOME/tofile-test" instead of the "-v file:/tmp/tofile-test", as it differs a bit where CUPS is allowed to create files). Is the result for 1-4 the same as when printing from Okular as before or is it different (e.g. correct printout on full A4 paper)? By the way, how are the printers set up on host B made available to host A? Are they explicitly set up there or are they advertised by host B and auto-discovered on host A? (An option "cups-browsed" can be seen in the error_log, which sounds like this might be a queue auto-discovered by cups-browsed, but I'm not sure.)
(In reply to Michael Weghorn from comment #19) > (In reply to Attila from comment #15) > > [...] > Can you try the following: > > 1) print the PDF file from another application on host A, e.g. from Evince > and from the command line using the following command: > > lp -d HPM880 -o PageSize=A4 <PDF_FILE> The result from the command line is OK. > > 2) print the PDF file directly on host B using the command line: > > lp -d HPM880 -o PageSize=A4 <PDF_FILE> The result from the command line is OK. > > 4) print the PDF file from Okular on host A with "Force rasterisation" > enabled in the print dialog under "Options" -> "PDF Options" The result from Okular is OK. > > By the way, how are the printers set up on host B made available to host A? > Are they explicitly set up there or are they advertised by host B and > auto-discovered on host A? (An option "cups-browsed" can be seen in the > error_log, which sounds like this might be a queue auto-discovered by > cups-browsed, but I'm not sure.) Fedora 26 is still running on Host B. Share printers is enabled. The service cups-browsed is running on host A to auto-discover the printers. I am going to send you all the other results you have requested on monday. Sorry for that.
Created attachment 110500 [details] What output looks like with scenario while trying to reproduce
(In reply to Attila from comment #20) > I am going to send you all the other results you have requested on monday. > Sorry for that. There's no need to apologize, that's just fine. :-) Thanks for all the additional information already provided. With this information, I was able to set up two virtual machines running Fedora 26 with a dummy printer "tofile-hp" (that prints to file) in order to reproduce the issue. I currently don't have the problem when printing the provided file from Okular on my "host A" to my "host B". However, I think I can reproduce by running the following command on "host A" (options taken from your error_log): $ lp -d tofile-hp -o "Collate cups-browsed finishings=3 fit-to-page job-billing job-sheets=none,none media=A4 number-up=1 number-up-layout=lrtb orientation-requested=0 outputorder=normal page-bottom=12 page-left=18 page-right=18 page-top=12 portrait print-quality=0 sides=one-sided Duplex=None PageSize=A4" d02917-001 This is basically similar to scenario 5 from comment 19, but without printing from Okular, but taking the file you provided as having been generated by Okular. Can you confirm that the output on your printer looks the same as the one I got with my "file" printer (after removing the PJL headers)? I attached this as https://bugs.kde.org/attachment.cgi?id=110500 . The given printer options might play a role. I will investigate further. If that's the output you also get, there's no need to test the other scenarios from comment 19 for now, since I should be able to reproduce by myself now.
I can reproduce the issue much more easily by just running the following command on host B: $ lp -d tofile-hp -o "fit-to-page orientation-requested=0" d02917-001 The problem you encounter seems to be related to those two options being set together. I'm wondering where the "orientation-requested=0" option comes from. The CUPS documentation [1] just lists the values 3,4,5 and 6 for the "orientation-requested" option. At first glance, it does not seem like either Okular or Qt would be setting anything for the "orientation-requested" option. ("git grep orientation-requested" in the Okular and Qt git repositories did not show any result.) For me, the option is not set at all either when when I print using Okular on Fedora 26. Is there any file $HOME/.cups/lpoptions or /etc/cups/lpoptions present on host A? Or do you have any other ideas where this option might come frome? [1] https://www.cups.org/doc/options.html
(In reply to Michael Weghorn from comment #22) > Can you confirm that the output on your printer looks the same as the one I > got with my "file" printer (after removing the PJL headers)? I attached this > as https://bugs.kde.org/attachment.cgi?id=110500 . Yes, I can confirm. This is exactly the output on my printer. > > The given printer options might play a role. I will investigate further. I agree. The given printer options play definitely a role.
(In reply to Michael Weghorn from comment #23) > I can reproduce the issue much more easily by just running the following > command on host B: > > $ lp -d tofile-hp -o "fit-to-page orientation-requested=0" d02917-001 > > The problem you encounter seems to be related to those two options being set > together. I can reproduce the issue too by running the command on Host A: lp -d tofile-hp -o "fit-to-page orientation-requested=0" d02917-001 > > I'm wondering where the "orientation-requested=0" option comes from. > The CUPS documentation [1] just lists the values 3,4,5 and 6 for the > "orientation-requested" option. > > At first glance, it does not seem like either Okular or Qt would be setting > anything for the "orientation-requested" option. ("git grep > orientation-requested" in the Okular and Qt git repositories did not show > any result.) For me, the option is not set at all either when when I print > using Okular on Fedora 26. > > Is there any file $HOME/.cups/lpoptions or /etc/cups/lpoptions present on > host A? > Or do you have any other ideas where this option might come frome? I have no clue where the option orientation-requested=0 comes from. The file $HOME/.cups/lpoptions on host A contains only the default printer like "Default HPM880". The file /etc/cups/lpoptions on host A is empty and on host B as well. Just one very interesting thing. I have installed the printer on host B and named it "HPM880Test". I am able to print on host A from Okular. The output is OK. Now it is getting weird. When I uninstall the printer "HPM880" and reinstall again on host B and name it again "HPM880" the output is again A5. I think it has something to do with the name. It must be somewhere in a file (configuration). > > > [1] https://www.cups.org/doc/options.html
Can you run the command "echo hello | lp -d HPM880" on host A and attach the corresponding CUPS error_log? (In reply to Attila from comment #25) > > I have no clue where the option orientation-requested=0 comes from. > The file $HOME/.cups/lpoptions on host A contains only the default printer > like "Default HPM880". > The file /etc/cups/lpoptions on host A is empty and on host B as well. I can barely imagine it will make a change, but can you delete (or rename) both files and see whether this changes anything? Are any such files present on host B as well? > > Just one very interesting thing. > I have installed the printer on host B and named it "HPM880Test". > I am able to print on host A from Okular. The output is OK. > Now it is getting weird. When I uninstall the printer "HPM880" and reinstall > again on host B and name it again "HPM880" the output is again A5. > I think it has something to do with the name. It must be somewhere in a file > (configuration). That's really interesting... Is there anything of interest in /etc/cups/printers.conf or /etc/cups/printers.conf.O on either host A or B?
Created attachment 110563 [details] error_log for echo hello...
(In reply to Michael Weghorn from comment #26) > Can you run the command "echo hello | lp -d HPM880" on host A and attach the > corresponding CUPS error_log? > > (In reply to Attila from comment #25) > > > > I have no clue where the option orientation-requested=0 comes from. > > The file $HOME/.cups/lpoptions on host A contains only the default printer > > like "Default HPM880". > > The file /etc/cups/lpoptions on host A is empty and on host B as well. > > I can barely imagine it will make a change, but can you delete (or rename) > both files and see whether this changes anything? No changes. > > Are any such files present on host B as well? lpoptions is empty on host B > > > > > Just one very interesting thing. > > I have installed the printer on host B and named it "HPM880Test". > > I am able to print on host A from Okular. The output is OK. > > Now it is getting weird. When I uninstall the printer "HPM880" and reinstall > > again on host B and name it again "HPM880" the output is again A5. > > I think it has something to do with the name. It must be somewhere in a file > > (configuration). > > That's really interesting... > Is there anything of interest in /etc/cups/printers.conf or > /etc/cups/printers.conf.O on either host A or B? printers.conf on Host A is empty. printers.conf on host B (see the attached file)
Created attachment 110564 [details] printers.conf on host B
(In reply to Attila from comment #27) > Created attachment 110563 [details] > error_log for echo hello... This one also contains "orientation-requested=0", so the fact that this is set is totally independent of Okular and I tend to say that we should close this bug here for that reason... Two last thoughts: * Does the problem also happen when you print as another user? * Does any of the following commands return any result? $ sudo grep -r orientation-requested /etc/ $ sudo grep -r orientation-requested /var/
And the last idea I can come up with right now is to set "LogLevel" to "debug2" in /etc/cups/cupsd.conf, print again and attach the error_log here.
Created attachment 110608 [details] error_log LogLevel debug2
(In reply to Michael Weghorn from comment #30) > (In reply to Attila from comment #27) > > Created attachment 110563 [details] > > error_log for echo hello... > > This one also contains "orientation-requested=0", so the fact that this is > set is totally independent of Okular and I tend to say that we should close > this bug here for that reason... Have you got an idea where to report the bug, if we close it here? What product or component? > > Two last thoughts: > > * Does the problem also happen when you print as another user? Yes, it does. > > * Does any of the following commands return any result? > > $ sudo grep -r orientation-requested /etc/ No result here. > $ sudo grep -r orientation-requested /var/ Here the result: ... /var/cache/cups/cups-browsed-options-HP9500DN:orientation-requested-default=no-value /var/cache/cups/cups-browsed-options-EPSON7900:orientation-requested-default=no-value /var/cache/cups/cups-browsed-options-HPM880:orientation-requested-default=no-value ... Interesting again, that the file /var/cache/cups/cups-browsed-options-HPM880Test (my Test printer) doesn't contain "orientation-requested". When I print to the printer HPM880 the file /var/cache/cups/cups-browsed-options-HPM880 is being written again, so it has no effect to delete the line "orientation-requested-default=no-value". It was my first thought to delete the line "orientation-requested-default=no-value". This information must come from somewhere else.
(In reply to Attila from comment #33) > > Have you got an idea where to report the bug, if we close it here? > What product or component? I'm not sure. The last information sounds like it might be related to cups-browsed, which is maintained as part of "cups-filters". The GitHub page is: https://github.com/OpenPrinting/cups-filters I'm not sure though. However, I think we can leave this bug open here until there's no more ideas on what to look at. In order to find out whether it's a cups-browsed problem, the following might help: > > * Does the problem also happen when you print as another user? > > Yes, it does. 1) Do you have another computer in addition to host a on which you could try? > > $ sudo grep -r orientation-requested /var/ > > Here the result: > > ... > /var/cache/cups/cups-browsed-options-HP9500DN:orientation-requested- > default=no-value > /var/cache/cups/cups-browsed-options-EPSON7900:orientation-requested- > default=no-value > /var/cache/cups/cups-browsed-options-HPM880:orientation-requested-default=no- > value > ... > > Interesting again, that the file > /var/cache/cups/cups-browsed-options-HPM880Test (my Test printer) doesn't > contain "orientation-requested". > > When I print to the printer HPM880 the file > /var/cache/cups/cups-browsed-options-HPM880 is being written again, so it > has no effect to delete the line "orientation-requested-default=no-value". > It was my first thought to delete the line > "orientation-requested-default=no-value". This information must come from > somewhere else. 2) Can you try to delete the file again after stopping cups-browsed? i.e. $ sudo systemctl stop cups-browsed.service $ sudo rm /var/cache/cups/cups-browsed-options-tofile-hp $ sudo systemctl start cups-browsed.service And then print again. 3) Set up the printer without using cups-browsed: * temporarily stop cups-browsed: 'sudo systemctl stop cups-browsed.service' * verify the printer is no longer shown when running 'lpstat -v' * set up the printer like this: 'sudo lpadmin -p HPM880 -v ipp://<HOST_B>/printers/HPM880 -E' (where '<HOST_B>' is the hostname or IP address of host B) * print to the printer * from Okular (and check result) * using 'echo hello | lp -d HPM880' and attaching the error_log from host A here * ('sudo lpadmin -x HPM880' and 'sudo cupsenable cups-browsed' will bring back the original setup.)
I have got great news. The following did it: $ sudo systemctl stop cups-browsed.service $ sudo rm /var/cache/cups/cups-browsed-options-tofile-hp $ sudo systemctl start cups-browsed.service The file /var/cache/cups/cups-browsed-options-HPM880 doesn't contain "orientation-requested-default=no-value" any more. I can print and the output is as it should be. Great, isn't it? Please leave this bug open for a couple of days, because I would like to monitor the result. I hope it will last for ever.
(In reply to Attila from comment #35) > I have got great news. > The following did it: > > $ sudo systemctl stop cups-browsed.service > $ sudo rm /var/cache/cups/cups-browsed-options-tofile-hp > $ sudo systemctl start cups-browsed.service > > The file /var/cache/cups/cups-browsed-options-HPM880 doesn't contain > "orientation-requested-default=no-value" any more. > I can print and the output is as it should be. Great, isn't it? Thanks for the update! I'm glad to hear this fixes the problem. It actually is/was a cups-browsed problem then. > Please leave this bug open for a couple of days, because I would like to > monitor the result. I hope it will last for ever. Please do leave a comment here what the result is and whether the problem reappears. However, I'm "officially" closing this bug report now, since the cause has been found (and is outside Okular). The fact that the bug is closed won't keep you from commenting and I'll also get a notification regardless of whether the bug is closed or not, so I don't think there's a real need to keep it open.
(In reply to Attila from comment #35) > I can print and the output is as it should be. Great, isn't it? > Please leave this bug open for a couple of days, because I would like to > monitor the result. I hope it will last for ever. I'm just curious about the result: Did the situation remain as it should be or did the problem reappear?
The problem didn't reappear, everything is fine. Thank you very much for your excellent support.
Great to hear. Thanks for the update!