[okular] [Bug 406237] PDFs get an added margin when printing

[Michael Weghorn]

https://bugs.kde.org/show_bug.cgi?id=406237

--- Comment #10 from Michael Weghorn <m.weghorn at posteo.de> ---
(In reply to Matthew Trescott from comment #7)
> [...]
> 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.

This didn't happen in my case. Can you attach the generated PostScript file as
well as the PPD of your printer here (which is located at
'/etc/cups/ppd/<PRINTERNAME>.ppd)?


> 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.

I guess the application *could* set the paper size. I'd say whether or not this
is desirable depends on the use case. As mentioned in my previous comment for
the real physical printer, I'm happy with the A4 default. In my opinion, this
is not a bug at a quick glance, but would rather be an enhancement request to
change it if you think using the current document's size should be preselected.
(Choosing the "correct" default is hard and you'll probably never find any that
everybody is happy with...)


> 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"

Whatever should be the "correct" default can for sure be discussed. Basically
the same as above: It's not really a bug in my opinion. If you think it should
be changed, I'd say: Feel free to file a request to change this and let's see
what decision will be taken.
Note that there's already bug 404510 that requests the possibilty to store the
preferred scaling setting, so maybe this would "fix" your case as well?


> > > - "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.

At a quick glance, there's mainly two options to handle the current options:

A) what happens currently: print margins are honoured; the document is not
scaled, so the painting starts at the top-left of the printable area with
original size. Whatever doesn't fit, just get's lost.
B) alternative: print margins are ignored when the "Print original size" is
selected. If the document has sufficient margins, this is fine, otherwise parts
might get cropped.

If the document is smaller than the paper size (e.g. printing A5 to A4) and the
document doesn't have proper margins, A) might be desirable, but I see that
e.g. when printing A4 to A4, B) may be preferrable.
I'm personally not sure how to best deal with this.
(The original suggestion in https://phabricator.kde.org/D7962 had two separate
options to select what kind of scaling to apply and whether or not to take
print margins into account, so the user would have been able to choose what
option to use here. However, a single combobox was considered to provide better
UX.)


> 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.

As mentioned above, I don't necessarily agree that all of these are actual
bugs. Feel free to continue discussion here for now or open a separate bug
report for every aspect to continue discussion there.

-- 
You are receiving this mail because:
You are the assignee for the bug.