When printing, some content near the margins is often cut out. Playing with the various printing options does not help. In all these cases, the print preview is correct, but still some of the content is cut. With another PDF viewing software the printout is correct. Attached a sample pdf file that triggers the behavior (on left and right margins), and a picture showing a particular of what comes out after printing. Reproducible: Always Steps to Reproduce: 1. Print a document like the one attached 2. 3. Actual Results: Some content near the margins in the printout is cut. Expected Results: Correct print as in the print preview. Printer: HP P4015n This bug refers to version 0.23.0
Created attachment 94244 [details] Example file that triggers the behavior
Created attachment 94245 [details] Particular of the printout
I wonder if my problem is the same? Or is mine a similar problem? When I try to print the PDF at http://www.ritetemp-thermostats.com/80XX/images/8082C_operation_guide.pdf , the printout has only part of the page. It is as if the page image had been enlarged, and the part of it gets printed on my 8.5 inch by 11 inch paper.
(In reply to James Funk from comment #3) > I wonder if my problem is the same? Or is mine a similar problem? When I > try to print the PDF at > http://www.ritetemp-thermostats.com/80XX/images/8082C_operation_guide.pdf , > the printout has only part of the page. It is as if the page image had been > enlarged, and the part of it gets printed on my 8.5 inch by 11 inch paper. I neglected to mention some things. I'm using a Brother HL-5140 laser printer, OpenSuSE 13.2
What version of cups? If 1.7.x, maybe a dup of bug #334653 and/or bug #330820
If I read software manager correctly, CUPS version is 1.5.4-21.9.1 (x86-64)
@Dario: Does this problem still exist with a current Okular version? If so: Can you please attach the PPD file of the printer in use (which should be located at /etc/cups/ppd/<PRINTERNAME>.ppd)?
Created attachment 111603 [details] HP Officejet 7110 ppd okular-17.12.1 I came to this bugreport while experiencing the problem on another PDF I was printing. In ppd folder there is also a ppd.o file, do you need it too?
(In reply to Germano Massullo from comment #8) > Created attachment 111603 [details] > HP Officejet 7110 ppd > > okular-17.12.1 > I came to this bugreport while experiencing the problem on another PDF I was > printing. > In ppd folder there is also a ppd.o file, do you need it too? I have forgotten to say that my distribution is Fedora 27
(In reply to Germano Massullo from comment #8) > Created attachment 111603 [details] > HP Officejet 7110 ppd > > okular-17.12.1 > I came to this bugreport while experiencing the problem on another PDF I was > printing. > In ppd folder there is also a ppd.o file, do you need it too? Thanks for attaching the PPD file. Can you also attach the PDF file with which you are experiencing the problem? Which page size is selected in the print dialog for the printer?
Created attachment 111657 [details] affected pdf (In reply to Michael Weghorn from comment #10) > Can you also attach the PDF file with which you are experiencing the problem? I attached it in a compressed version it to avoid indexing from internet search engines. The cutted parts are: - upper part of logo in upper margin of the page - bottom text in bottom part of the page. I experienced the problem also with other documents. Evince instead prints the document correctly > Which page size is selected in the print dialog for the printer? In HP Device Manager: A4 Autoduplex 210x297mm in Okular: A4 210x297mm
The error_log from CUPS (the printing system) might help to further analyse this. Can you set the 'LogLevel' directive in '/etc/cups/cupsd.conf' to 'LogLevel debug', restart CUPS ('sudo systemctl restart cups.service') and print again? Depending on the CUPS configuration, the relevant log output will then either go to the file '/var/log/cups/error_log' or can be seen with the command 'sudo journalctl _SYSTEMD_UNIT=cups.service'. Can you attach the error_log or the output of the above command here? It would also be helpful if you could attach the file generated by Okular for printing. This one will be located at '/var/spool/cups/d<JOB_ID>_001' (where '<JOB_ID>' is replaced by the actual job ID).
Created attachment 111689 [details] cups debug log
(In reply to Michael Weghorn from comment #12) > It would also be helpful if you could attach the file generated by Okular > for printing. This one will be located at '/var/spool/cups/d<JOB_ID>_001' > (where '<JOB_ID>' is replaced by the actual job ID). # ls /var/spool/cups/ returns a list of files of c<JOB_ID> I took the file of lastest print job ID, and its size is 1,5 kB. Is it the file you asked for? Best regards
(In reply to Germano Massullo from comment #14) > # ls /var/spool/cups/ > returns a list of files of c<JOB_ID> > I took the file of lastest print job ID, and its size is 1,5 kB. Is it the > file you asked for? > > Best regards Thanks for the additional information. Hm, no the c<JOB_ID> files are something different. You might have to set 'PreserveJobFiles Yes' in '/etc/cups/cupsd.conf' and restart CUPS in order for the "correct" files to be preserved there after printing. Can you try to print again after setting this? (You can also use 'PreserveJobFiles 86400', which will just keep the 'd<JOB_ID> file for one day or reset to 'No' afterwards, since keeping all documents forever might consume quite some space after a while if you print a lot...). Unfortunately, the cups error log does not contain all of the information I expected. There should usually be more information on the print processing, e.g. some lines with 'argv' in them, e.g. 'argv[5]' would show the options passed to CUPS. Did the print job finish before you copied the file? May I ask you to do this once again to see whether the information is contained then?
The information requested in comment 15 is needed to further analyse this issue.
Created attachment 111855 [details] d01250-001 Solved with 'PreserveJobFiles Yes' in '/etc/cups/cupsd.conf'
(In reply to Germano Massullo from comment #17) > Created attachment 111855 [details] > d01250-001 > > Solved with 'PreserveJobFiles Yes' in '/etc/cups/cupsd.conf' I mean I managed to get the job file
(In reply to Germano Massullo from comment #18) > (In reply to Germano Massullo from comment #17) > > Created attachment 111855 [details] > > d01250-001 > > > > Solved with 'PreserveJobFiles Yes' in '/etc/cups/cupsd.conf' > > I mean I managed to get the job file Thanks for attaching the job file. This is actually the PostScript file that is generated by Okular and passed to the printing system CUPS. The file looks totally OK in my eyes; you can open it for viewing in Okular. In my understanding, this suggests that the problem is only introduced during the processing inside CUPS (the printing system, e.g. by one of the CUPS filters or the printer itself). Unless Okular passes any "wrong" options, the problem probably lies outside of Okular's responsibility. In order to have a closer look at this, it would be necessary to see which options are actually passed to CUPS. Unfortunately those were not shown in the log output of comment 13. Was this the output of the command 'sudo journalctl _SYSTEMD_UNIT=cups.service'? If so, could you please try to change the 'ErrorLog' directive in '/etc/cups/cups-files.conf' to 'ErrorLog /var/log/cups/error_log', restart cups ('sudo systemctl restart cups.service'), print again and attach the log file '/var/log/cups/error_log' that should have been created by then. (The mentioned directive makes the output written to this file instead of syslog/journal, in case the previous directive was 'ErrorLog syslog'.) Some more thoughts: How is the printer connected (e.g. a locally connected USB printer or a network printer or a printer shared from another host)? Can you please post the output of the command 'lpstat -v' (or 'lpstat -v | grep <YOURPRINTERNAME>')? Is there any file '/etc/cups/lpoptions' or '$HOME/.cups/lpoptions' present? What happens if you print the job file attached in comment 17 directly from the command line using the command 'lp -d <YOURPRINTERNAME> d01250-001' from a directory where this file is located? Is the output the same?
Just to clarify my experience while waiting for his response. It happened to me some time ago with a certain configuration to a network printer managed outside my control, and a certain printer driver (I cannot remember anymore). Only on Okular, Evince and other softwares printed fine. After they have made some obscure updates to the network printing system and changed the authenthication (it is also possible I selected a different driver from CUPS list, there were many applicable to the Hp P4015n), I have not experienced the bug anymore.
Created attachment 111870 [details] error_log I changed the 'ErrorLog' directive in '/etc/cups/cups-files.conf' to 'ErrorLog /var/log/cups/error_log' # lpstat -v dispositivo per Officejet_7110: hp:/net/Officejet_7110_series?ip=**removed by me**
(In reply to Michael Weghorn from comment #19) > How is the printer connected (e.g. a locally connected USB printer or a > network printer or a printer shared from another host)? Network printer directly connected to the network > > Is there any file '/etc/cups/lpoptions' or '$HOME/.cups/lpoptions' present? Both yes > > What happens if you print the job file attached in comment 17 directly from > the command line using the command 'lp -d <YOURPRINTERNAME> d01250-001' from > a directory where this file is located? Is the output the same? lp: No such file or directory
Created attachment 111896 [details] Test PDF file generated while trying to reproduce the problem
@Dario: Thanks for the update. Good to hear you're no longer having the problem. This also confirms my assumption that the problem is/was somewhere during the print processing. @Germano: Thanks for the additional info. That new 'error_log' does actually contain the required information and I think I can somewhat reproduce the issue in a Fedora 27 VM now. (not using a real printer and just running part of the CUPS filters and using an external tool to view the generated file, but the result looks like it should be what you described). Can you confirm that attachment 111896 [details] resembles the output you get on your real printer? (In reply to Germano Massullo from comment #21) > Created attachment 111870 [details] > error_log > > I changed the 'ErrorLog' directive in '/etc/cups/cups-files.conf' to 'ErrorLog/var/log /cups/error_log' Thanks, this helps! (In reply to Germano Massullo from comment #22) > > > > Is there any file '/etc/cups/lpoptions' or '$HOME/.cups/lpoptions' present? > > Both yes Can you please try to delete or temporarily rename those, print again and see whether this resolves the issue? In case the thing I can reproduce is actually representative for your problem as well, the problem is related to the print options that are passed to CUPS in your setup. I cannot reproduce with the options that are passed when I print the document to my dummy printer in my Fedora VM. > > > > > What happens if you print the job file attached in comment 17 directly from > > the command line using the command 'lp -d <YOURPRINTERNAME> d01250-001' from > > a directory where this file is located? Is the output the same? > > lp: No such file or directory Sorry if my instructions were not clear enough. This command would have to be run from a directory where attachment 111855 [details] was downloaded and extracted (I guess you put the original file into a tar.gz archive and it was not like that in the '/var/spool/cups/' directory). Anyway, in case removing the two 'lpoptions' files resolves your problem, that test is no longer needed in my eyes.
(In reply to Michael Weghorn from comment #24) > @Germano: Thanks for the additional info. That new 'error_log' does actually > contain the required information and I think I can somewhat reproduce the > issue in a Fedora 27 VM now. (not using a real printer and just running part > of the CUPS filters and using an external tool to view the generated file, > but the result looks like it should be what you described). > > Can you confirm that attachment 111896 [details] resembles the output you > get on your real printer? Yes it has exactly the same cutted parts (upper and bottom side of the document) > (In reply to Germano Massullo from comment #22) > > > > > > Is there any file '/etc/cups/lpoptions' or '$HOME/.cups/lpoptions' present? > > > > Both yes > > Can you please try to delete or temporarily rename those, print again and > see whether this resolves the issue? # mv /etc/cups/lpoptions /etc/cups/lpoptions_OLD $ mv .cups/lpoptions .cups/lpoptions_OLD # systemctl restart cups then I printed the document and the margins were perfect. To double check I runned # mv /etc/cups/lpoptions_OLD /etc/cups/lpoptions $ mv .cups/lpoptions_OLD .cups/lpoptions # systemctl restart cups and I printed again, **BUT** this time the margins were perfect too. I think this is very confusing. How could you explain the perfect margins even resuming old files? > > > What happens if you print the job file attached in comment 17 directly from > > > the command line using the command 'lp -d <YOURPRINTERNAME> d01250-001' from > > > a directory where this file is located? Is the output the same? > > > > lp: No such file or directory > > Sorry if my instructions were not clear enough. This command would have to > be run from a directory where attachment 111855 [details] was downloaded and > extracted (I guess you put the original file into a tar.gz archive and it > was not like that in the '/var/spool/cups/' directory). > Anyway, in case removing the two 'lpoptions' files resolves your problem, > that test is no longer needed in my eyes. Ok so I did not run it
(In reply to Germano Massullo from comment #25) > Yes it has exactly the same cutted parts (upper and bottom side of the > document) Thanks for the confirmation. > > (In reply to Germano Massullo from comment #22) > # mv /etc/cups/lpoptions /etc/cups/lpoptions_OLD > $ mv .cups/lpoptions .cups/lpoptions_OLD > # systemctl restart cups > then I printed the document and the margins were perfect. So the problem actually is some print options that are set "outside the control of Okular". > > To double check I runned > # mv /etc/cups/lpoptions_OLD /etc/cups/lpoptions > $ mv .cups/lpoptions_OLD .cups/lpoptions > # systemctl restart cups > and I printed again, **BUT** this time the margins were perfect too. I think > this is very confusing. How could you explain the perfect margins even > resuming old files? That's really surprising. Does this mean that you can no longer reproduce the original problem at all? In the end, the print options that are/were effectively set did cause the problem, so you might want to have a look at the CUPS error_log again and compare the value of "argv[5]" (i.e. the options passed to CUPS for the print job) to those that were set previously (where the problem occured) -- and then look at what the two 'lpoptions' files contain and what options are no longer applied. In any case: Do you think we can close this bug report as "WORKSFORME" or "UPSTREAM", since you don't seem to have the problem any longer and it seems to have been caused by options set outside of Okular? (We can still discuss on why the options are no longer set after renaming the lpoptions files twice, regardless of whether the bug is open or not.)
Let me try with some other computers
Germano, any success with testing on different computers?
No response, changing status. If you have new information, please add a comment.
I tried to print using other computer and I had no problems No problem with (In reply to Michael Weghorn from comment #26) > (We can still discuss on why the options are no longer set after renaming > the lpoptions files twice, regardless of whether the bug is open or not.) Yes I would be interested in discussing this
(In reply to Germano Massullo from comment #30) > I tried to print using other computer and I had no problems I'm glad to hear this. > Yes I would be interested in discussing this OK. Do you have a way to reproduce this in some way? (Otherwise it's impossible to further investigate the issue.)
(In reply to Michael Weghorn from comment #31) > (In reply to Germano Massullo from comment #30) > > Yes I would be interested in discussing this > > OK. Do you have a way to reproduce this in some way? (Otherwise it's > impossible to further investigate the issue.) Unfortunately I am no longer able to reproduce the issue :-(
(In reply to Germano Massullo from comment #32) > (In reply to Michael Weghorn from comment #31) > > (In reply to Germano Massullo from comment #30) > > > Yes I would be interested in discussing this > > > > OK. Do you have a way to reproduce this in some way? (Otherwise it's > > impossible to further investigate the issue.) > > Unfortunately I am no longer able to reproduce the issue :-( Then I'd suggest to just be happy things are working as expected now. Should the problem still reappear at any point in time, there's still the option to investigate it again...
Created attachment 115965 [details] affected document 2 Experiencing again this problem on a different computer + different printer. I attach the PDF, I will provide the other needed infos + tests as soon as possible
Can you please tell me where I can add the missing PreserveJobFiles entry in my cupsd.conf file? https://paste.fedoraproject.org/paste/eViZES2mtZ7TaK71JxFa8g
(In reply to Germano Massullo from comment #35) > Can you please tell me where I can add the missing PreserveJobFiles entry in > my cupsd.conf file? > https://paste.fedoraproject.org/paste/eViZES2mtZ7TaK71JxFa8g Due to my late reply, the above URL is no longer valid. However, you can just add the line "PreserveJobFiles Yes" into your cupsd.conf pretty much anywhere, e.g. at the very top and restart CUPS so that the setting is actually applied. Can you also attach the /etc/cups/lpoptions and ~/.cups/lpoptions files, if present, as well as the corresponding lines from the CUPS log (as previously, in particular those containing the 'argv[...]' lines)?
Setting status to WAITINGFORINFO (s. comment 36).
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Created attachment 129046 [details] scanned Evince-20.04 and Okular-3.36.1 printings I can reproduce the problem with the original attachment: https://bugs.kde.org/attachment.cgi?id=94244 I attached a photo. (printed with Debian, see below) Left on the photo is Evince, right is Okular. You can clearly see, that Okular cuts the first letter of each line. Additionally Okular shrinks the document too much. Evince can print the document without (so much) shrinking. I have other documents where Okular also cuts the lower end. I've tested this with Debian and openSUSE and Okular always gets it wrong, and Evince always gets it correct. Debian-Testing (11 a.k.a Bulleye 2020-06-03) Okular-20.04 (a.k.a 1.10.0) Evince-3.36.1 Printer: HP Deskjet 1000 j110 Series, hpcups 3.20.5 openSUSE-15.1 Okular 18.12.3 (1.6.3) Evince 3.26.0 Printer: HP Deskjet 1000 j110 Series, hpcups 3.12.11
Created attachment 129047 [details] jobs from /var/spool/cups/ on Debian (Okular is 8, Evince is 9)
P.S. The Debian-Testing (Bullseye) system is freshly set up and I changed any Okular or printing dialog settings. So it's all still at default (margins, etc., ...).
(In reply to kolAflash from comment #40) > Created attachment 129046 [details] > scanned Evince-20.04 and Okular-3.36.1 printings > > I can reproduce the problem with the original attachment: > https://bugs.kde.org/attachment.cgi?id=94244 > [...] Please create a new bug report and leave a link here. (And also attach CUPS's error log with LogLevel set to "debug" in /etc/cups/cupsd.conf, and your printer's PPD, located at /etc/cups/ppd/<PRINTERNAME>.ppd)
(In reply to Michael Weghorn from comment #43) > [...] > Please create a new bug report and leave a link here. > > (And also attach CUPS's error log with LogLevel set to "debug" in > /etc/cups/cupsd.conf, and your printer's PPD, located at > /etc/cups/ppd/<PRINTERNAME>.ppd) Done: https://bugs.kde.org/show_bug.cgi?id=422690