Created attachment 119162 [details] Okular will not print the text in this PDF on my printer. Hi, I just printed a PDF document (A4 format) and noticed that a small part of the document (around 3cm) is cut off at the top and the bottom of the page. At first I thought that this was a limitation of the printer, but this is not actually the case since this problem doesn't happen when printing from Evince. I also compared the printouts of Evince and Okular, and they are otherwise exactly the same. All the other elements on the page show up in the exact same place on the paper, so Evince doesn't appear to perform any sort of "shrink-to-fit" magic that might otherwise explain this behaviour. I'm using CUPS 2.2.8 with a Brother HL-2030. The driver is "Brother HL-2030 Foomatic/hl1250 (recommended)" The default settings are "job-sheets=none, none media=iso_a4_210x297mm sides=one-sided"
Some questions to narrow this further down: 1) Can you attach the PPD file of the printer, which should be located at /etc/cups/ppd/<PRINTERNAME>.ppd ? 2) Can you attach a CUPS debug log when doing such a printout? (set 'LogLevel debug' in /etc/cups/cupsd.conf, then restart CUPS, print, and attach /var/log/cups/error_log (or the relevant part of it). (Depending on the setting for 'ErrorLog' in /etc/cups/cups-files.conf, the log output may alternatively go to the journal, so either retrieve it from there or set 'ErrorLog /var/log/cups/error_log'
Created attachment 128284 [details] CUPS debug log file
Created attachment 128285 [details] The PPD file
Hey @Michael Weghorn, Sorry for the delay, I have attached the data that you requested. I have also tried to reproduce the bug in Okular 1.9.3 and it still behaves the same, so I bumped the version too.
answer was given
Created attachment 128297 [details] pcapng trace of the IPP traffic Hey, I thought in order to debug this it might be helpful to see the IPP traffic that Okular and CUPS exchange, so I've recorded said traffic with Wireshark. It's encrypted using TLS, but I've included the decryption secrets with editcap as described here: https://wiki.wireshark.org/TLS#TLS_Decryption So you should be able to see the unencrypted traffic
Created attachment 128298 [details] pcapng trace of the IPP traffic created by evince Here's what Evince does, it works there. Maybe it helps when you can compare what the two programs are doing.
Created attachment 128306 [details] The PDF that Okular sends to the printer via IPP Hey, I've looked at the IPP traffic that I uploaded earlier using Wireshark, and I found that Okular transmits the data to be printed in PDF format. So I extracted that PDF from the pcapng capure file, saved it to disk, opened it with Okular and found… a blank page with nothing on it. So that seems to be why nothing is printed. I'm attaching said PDF here in the hope that it helps to figure out what's going on.
Created attachment 128310 [details] Another example I'm adding another example that hopefully makes it a bit easier to see what I'm talking about
Created attachment 128311 [details] Second example after it's been mangled by okular This is what's left of the PDF when Okular sends it to CUPS via IPP
(In reply to Matthias from comment #8) > I've looked at the IPP traffic that I uploaded earlier using Wireshark, and > I found that Okular transmits the data to be printed in PDF format. > > So I extracted that PDF from the pcapng capure file, saved it to disk, > opened it with Okular and found… a blank page with nothing on it. So that > seems to be why nothing is printed. I'm attaching said PDF here in the hope > that it helps to figure out what's going on. That's interesting, since Okular usually generates PostScript for printing by default. Okular does not generate IPP data itself, but uses the 'lpr' or 'lp' command to pass the file to CUPS (or in the case of "Force rasterization" checkbox sent, the Qt library handles passing the file to CUPS). (In reply to Matthias from comment #10) > Created attachment 128311 [details] > Second example after it's been mangled by okular > > This is what's left of the PDF when Okular sends it to CUPS via IPP Some more questions: 1) Did you select any additional information in the print dialog, e.g. set the "Force rasterization" checkbox? 2) What margins are set when you check that in the "Properties" dialog in the print dialog? Does changing all margins to 0 make a difference? 3) What "Scale mode" is selected in the "PDF Options" tab in the print dialog? 4) The file passed to the CUPS Printing system for a print job is saved in /var/spool/cups/d<PRINTJOB_ID>-001. Can you attach that file as well? That should be a PostScript or PDF file. You might have to set 'PreserveJobFiles Yes' in /etc/cups/cupsd.conf in case the file is not present in your case.
(In reply to Michael Weghorn from comment #11) > 1) Did you select any additional information in the print dialog, e.g. set > the "Force rasterization" checkbox? No, I haven't done anything in particular. Force rasterization is off. > 2) What margins are set when you check that in the "Properties" dialog in > the print dialog? Does changing all margins to 0 make a difference? 6.35mm on the left and right, 12.7mm on the top and the bottom. It can't change them to 0, the GUI won't allow me to change them to anything less than these values. > 3) What "Scale mode" is selected in the "PDF Options" tab in the print > dialog? Fit to printable area > 4) The file passed to the CUPS Printing system for a print job is saved in > /var/spool/cups/d<PRINTJOB_ID>-001. Can you attach that file as well? That > should be a PostScript or PDF file. You might have to set 'PreserveJobFiles > Yes' in /etc/cups/cupsd.conf in case the file is not present in your case. I'll attach it.
Created attachment 128402 [details] PostScript file from /var/spool/cups I'm completely confused by this. The PostScript file looks just like it's supposed to.
Just to be clear: The PostScript file looks fine when viewed in Okular, the printout is still broken.
(In reply to Matthias from comment #12) > (In reply to Michael Weghorn from comment #11) > > > 1) Did you select any additional information in the print dialog, e.g. set > > the "Force rasterization" checkbox? > No, I haven't done anything in particular. Force rasterization is off. What happens if you switch it on? > > 2) What margins are set when you check that in the "Properties" dialog in > > the print dialog? Does changing all margins to 0 make a difference? > 6.35mm on the left and right, 12.7mm on the top and the bottom. It can't > change them to 0, the GUI won't allow me to change them to anything less > than these values. > > > 3) What "Scale mode" is selected in the "PDF Options" tab in the print > > dialog? > Fit to printable area That's interesting. At a quick glance, attachment 128311 [details] looks like the missing content might pretty much match the page margins, i.e. the non-printable area of the printer ("6.35mm on the left and right, 12.7mm on the top and the bottom". However, if "fit to printable area" is selected, the content should automatically scaled down by CUPS, since it is passed the "fit-to-page" option, which can also be seen in your error_log: Mai 09 14:52:14 localhost.localdomain cupsd[126424]: argv[5]="Collate finishings=3 fit-to-page job-billing media=A4 number-up=1 number-up-layout=lrtb outputorder=normal page-bottom=36 page-left=18 page-right=18 page-top=36 portrait sides=one-sided job-uuid=urn:uuid:f319f4b2-6461-357b-7ff1-f7b3153c271b job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1589028734 time-at-processing=1589028734 document-name-supplied=okular_PwkqEO.ps PageSize=A4" What happens if you print the original PDF file and the generated PostScript file using 'lp' from command line, i.e. passing it directly to CUPS rather than using Okular? i.e. lp -d HL-2030-series -o fit-to-page -o PageSize=A4 <YOUR_PDF_FILE> and lp -d HL-2030-series -o fit-to-page -o PageSize=A4 d00129-001.ps
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!