https://bugs.kde.org/show_bug.cgi?id=406237
--- Comment #7 from Matthew Trescott <matthewtresc...@gmail.com> --- (In reply to Michael Weghorn from comment #6) > For real CUPS queues, Okular defaults to the default paper size set for the > given queue. Therefore, it defaults to A4 if A4 is set as the default paper > size and e.g. to A6 if A6 is set as the default paper size (as can be done > e.g. using the command 'lpoptions -p <PRINTERNAME> -o PageSize=A6'). > I personally like this behaviour, since my printer only has A4 paper loaded, > and I don't even have paper in US Letter size, so want to print documents in > US letter size on A4 paper. > I do understand that others may prefer another behaviour, though. No, the behavior you described is perfect for printing with a physical printer. But it doesn't actually work (see below). > > - On physical printers, Okular seems to ignore the paper size setting in the > > Printer Properties dialog. > > Can you elaborate on this? > In my case, selecting e.g. A5 as paper size in Okular will result in only > the area of an A5 page being printed upon on the A4 paper, and the rest > remaining blank. > Choosing A4 will result in the A4 area being printed upon (except margins, > depending on the scaling settings). I just double-checked this to make certain. I turned off WiFi temporarily so CUPS would hold my print job (it's a network printer), then printed my Letter-size PDF. I double-checked the printer properties in Okular to make sure that it was set to Letter (Letter is the default for the print queue so the paper size was already correctly set). However, when I opened the corresponding PostScript document in /var/spool/cups, it had the distinctive sqrt(2) side ratio of A-size paper. This confirms the results I had when I permitted the print jobs to go through previously and discovered this bug---I just didn't want to waste paper this time. Summary: the bug here is that Okular always prints in A4 to physical printers, even when a different paper size has been selected. > > - When using Print to PDF, Okular defaults to A4 even when the input > > document size is Letter. Changing the paper size in Printer Properties > > actually takes effect, however. > > Without checking, I'd guess that this comes from the Qt print dialog which > Okular uses. But mightn't it be the responsibility of the application using the Qt print dialog (Okular in this case) to tell Qt what paper size to default to for "Print to PDF"? My wild guess at the internals of how this works is just that the application provides a PDF which Qt forwards unmodified to the OS's print server, along with the metadata needed to adjust the printer settings. I doubt the Qt print dialog would be smart enough to parse the PDF it gets (if indeed my theory of how it works is correct) to figure out what paper size to use. Summary: the bug here is that the Printer Properties dialog for Print to PDF defaults to A4 for the paper size, rather than the size of the document being printed. > > However, even when the paper size for Print to PDF is corrected (set to > > Letter in my case), enabling "Force rasterization" produces incorrect > > results when the following scaling settings are used: > > > > - "Fit to printable area" results in the entire document being scaled down, > > although the margins are already more than sufficient for printing. > > As far as I understand, this "works as designed". Okular doesn't take into > account the margins already in the document, but scales the whole document > (including what you already see as margins) to fit into the printable area, > i.e. the whole output paper size from which the printer margins (as set in > the print dialog's "Properties" -> "Page" tab) are subtracted (which > defaults to the printer's hardware margins for physical printers or some > other minimum value e.g. for the "Print to PDF" case; I think that's from > the Qt print dialog and nothing Okular-specific). > > Does this work as expected if you manually set the margins there to 0? Ah, yes. It does work, and it makes sense since PDF files don't seem to have any semantic concept of margins. But in that case, "Fit to printable area" should not be the default scaling setting, since it adds margins where most PDFs will probably not need them. Summary: the bug here is that that the "Fit to printable area" scaling setting is the default, rather than "Fit to full page" > > - "Print original size" shifts the entire document down and to the right. > > I can confirm this with default margins set. Again: Does this still happen > when you set all margins to 0? (no longer happens then in my case) > This might need a closer look, not sure if it's supposed to work like this. Indeed, setting margins to zero does cause it to be positioned correctly. However, I would guess this setting should be called "crop to fit printable area" and make the horizontal cropping equal between the left and right sides, and the vertical cropping equal between top and bottom. Currently it's not very useful. Summary: the bug here is that "Print original size" shifts the document content to fit the top and left margins, rather than cropping the document on all sides to fit the margins. ---- Whew! That's actually four bugs in one! Hopefully my descriptions can just be copy-pasted into separate bug reports if you agree that these are all valid bugs. Thanks for looking into this. If this report gets split into multiple reports of course I don't mind this one being closed. -- You are receiving this mail because: You are watching all bug changes.
