I experience the following bug from 2015 in current Okular-1.10.0. (1.10.1 was closest available in bug properties) Abstract: Okular cuts margins for many documents when printing. Tried a lot of settings in Okular, but that made no difference. Evince gets everything correct. https://bugs.kde.org/show_bug.cgi?id=351849 Please also see my comments and attachments there: https://bugs.kde.org/show_bug.cgi?id=351849#c40 https://bugs.kde.org/show_bug.cgi?id=351849#c41 https://bugs.kde.org/show_bug.cgi?id=351849#c42 As asked by Michael Weghorn in #351849 comment 43 I provide more data in the attached file. I've tested this with Debian and openSUSE and Okular always gets it wrong, and Evince always gets it correct. Both os (openSUSE and Debian) run on German localization. But for testing on Debian I started okular with LANG=C.UTF-8. I print on German A4 standard paper. The only Okular setting that made a difference was, to set margins to 0mm instead of 3,53mm or 14,48mm. But it resulted only in scaling up the whole cut printout. (see okular_margins-0.jpeg) Attention: Mind the extra scanning margins around the printout images! 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 129168 [details] different logs and printouts (mind extra scanning margins)
Created attachment 129185 [details] a more common example (lower lines like "gemäße Abbuchung möglich machen." will be cut)
(In reply to kolAflash from comment #1) > Created attachment 129168 [details] > different logs and printouts (mind extra scanning margins) At a quick glance, the Postscript file generated by Okular looks OK to me (file 'debian_11-beta-20200609/var/spool/cups/d00018-001_-_print-area' in the attached tar file); if you open that in Okular, it looks the same as the PDF file 'numeric_test.pdf'. The processing to fit that to the page etc. is done by CUPS (and the corresponding so-called CUPS filters), according to the options Okular passes, which are those for the first case (from the error_log file): > D [09/Jun/2020:21:25:03 +0200] [Job 18] argv[5]="Collate ColorModel=KGray finishings=3 fit-to-page job-billing media=A4 number-up=1 number-up-layout=lrtb outputorder=normal page-bottom=41 page-left=10 page-right=10 page-top=10 portrait sides=one-sided job-uuid=urn:uuid:c 7d3001b-0e41-33d2-5eec-70168aa8d6ee job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1591730703 time-at-processing=1591730703 document-name-supplied=okular_ufzIXL.ps PageSize=A4" This looks OK to me at a quick glance. Therefore, this might be an issue outside of Okular. Some questions: 1) What happens if you print that file using the same options using command line, i.e.: lp -d HP_DeskJet_1000_at_fbox_hpcups -o "Collate ColorModel=KGray finishings=3 fit-to-page job-billing media=A4 number-up=1 number-up-layout=lrtb outputorder=normal page-bottom=41 page-left=10 page-right=10 page-top=10 portrait sides=one-sided job-uuid=urn:uuid:c 7d3001b-0e41-33d2-5eec-70168aa8d6ee job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1591730703 time-at-processing=1591730703 document-name-supplied=okular_ufzIXL.ps PageSize=A4" debian_11-beta-20200609/var/spool/cups/d00018-001_-_print-area 2) Does it make any difference if you just use this command? lp -d HP_DeskJet_1000_at_fbox_hpcups -o fit-to-page debian_11-beta-20200609/var/spool/cups/d00018-001_-_print-area 3) What happens if you print the PDF file numeric_test.pdf_able-job_1474.pdf from Okular to the CUPS-PDF printer instead of your physical one? (seems to work fine for me on Debian testing) 4) Do you have any other printer you can test with, and if so, how does it behave?
Created attachment 129577 [details] d00018-001_-_print-area to CUPS-PDF (In reply to Michael Weghorn from comment #3) > [...] > 1) What happens if you print that file using the same options using command > line, i.e.: > > lp -d HP_DeskJet_1000_at_fbox_hpcups -o "Collate ColorModel=KGray > finishings=3 fit-to-page job-billing media=A4 number-up=1 > number-up-layout=lrtb outputorder=normal page-bottom=41 page-left=10 > page-right=10 page-top=10 portrait sides=one-sided job-uuid=urn:uuid:c > 7d3001b-0e41-33d2-5eec-70168aa8d6ee job-originating-host-name=localhost > date-time-at-creation= date-time-at-processing= time-at-creation=1591730703 > time-at-processing=1591730703 document-name-supplied=okular_ufzIXL.ps > PageSize=A4" debian_11-beta-20200609/var/spool/cups/d00018-001_-_print-area Margins cut. > 2) Does it make any difference if you just use this command? > > lp -d HP_DeskJet_1000_at_fbox_hpcups -o fit-to-page > debian_11-beta-20200609/var/spool/cups/d00018-001_-_print-area Margins cut (exactly as above). And additionally scaled down a little (maybe 1%). > 3) What happens if you print the PDF file numeric_test.pdf_able-job_1474.pdf > from Okular to the CUPS-PDF printer instead of your physical one? (seems to > work fine for me on Debian testing) See attachment. > 4) Do you have any other printer you can test with, and if so, how does it > behave? No, but I remember similar problems with the printer at work (I think it's an HP too). But I won't be in the office for some time because of Covid-19. Could you ask the Evince/Gnome people for advice? Maybe it's a special trick they are intentionally applying. Because with Evince it's really everything correct.
Since this works OK with CUPS-PDF and the same issue happens when printing using command line, I think this is not an Okular issue, but rather somewhere in the CUPS filter chain. Closing as RESOLVED UPSTREAM accordingly. (In reply to kolAflash from comment #4) > Could you ask the Evince/Gnome people for advice? > Maybe it's a special trick they are intentionally applying. > Because with Evince it's really everything correct. Evince generates PDF print data, whereas Okular (by default) generates PostScript print data, so the CUPS filter chain is a different one in that case. Can you try whether setting the "Force rasterization" option in the "PDF options" tab of the print dialog works for you as a workaround?
(In reply to Michael Weghorn from comment #5) > Since this works OK with CUPS-PDF and the same issue happens when printing > using command line, I think this is not an Okular issue, but rather > somewhere in the CUPS filter chain. > Closing as RESOLVED UPSTREAM accordingly. Opened an issue for CUPS. https://github.com/OpenPrinting/cups-filters/issues/250 I'd be grateful if you have an eye on that issue and may help answering upcoming questions regarding Okular. > Can you try whether setting the "Force rasterization" option in the "PDF > options" tab of the print dialog works for you as a workaround? Indeed, "Force rasterization" workarounds the issue. I guess enabling rasterization by default would cause other problems? (I actually didn't open this issue for myself, but because other users have the same problem in the company I'm working for - so I'd be grateful for a general solution)
(In reply to kolAflash from comment #6) > Opened an issue for CUPS. > https://github.com/OpenPrinting/cups-filters/issues/250 > I'd be grateful if you have an eye on that issue and may help answering > upcoming questions regarding Okular. I've subscribed there. > > Can you try whether setting the "Force rasterization" option in the "PDF > > options" tab of the print dialog works for you as a workaround? > > Indeed, "Force rasterization" workarounds the issue. > > I guess enabling rasterization by default would cause other problems? > (I actually didn't open this issue for myself, but because other users have > the same problem in the company I'm working for - so I'd be grateful for a > general solution) Rasterization basically means that images are generated, so the files can become rather large, which can e.g. result in more memory being required and/or slower printing. Assuming this is actually a bug somewhere in the CUPS filter chain, I'm closing this bug report as UPSTREAM for now.