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

[Michael Weghorn]

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

Michael Weghorn <m.weghorn at posteo.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WAITINGFORINFO
             Status|REOPENED                    |NEEDSINFO

--- Comment #6 from Michael Weghorn <m.weghorn at posteo.de> ---
Thanks for testing and sorry for closing the bug so quickly.

(In reply to Matthew Trescott from comment #5)
> Okay, this is NOT a duplicate. Please read it carefully and test it for
> yourself. The default settings still produce poor results, although it as
> now at least possible to get suitable output.

I have tested myself. All tests involving a real physical printer in the
following refer to printing on am HP Officejet 4620.
Tests were done using the current Okular development version (as of commit
1f08c4724520414611e3eb3d6719ff9ef1209d5f) on Debian testing (with Qt 5.11.3).

> The main problem seems to be that Okular defaults to A4 paper regardless of
> the paper size of the input document.

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.


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


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

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


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

> To summarize, the only settings that produce normal print output for a
> standard 8.5 x 11" document are either:
> 
> - Print to PDF with the paper size manually set to Letter instead of A4
> _AND_ "Force rasterization" disabled.
> - Print to PDF with the paper size manually set to Letter instead of A4
> _AND_ "Force rasterization" enabled _AND_ scaling set to "Fit to full page"
> 
> I don't mean to be the unhappy customer when I didn't pay for the software,
> but in the future it would be nice to have bug reports verified fixed before
> they're closed as duplicates. It would make reporting bugs so much easier if
> I didn't have to put this much effort into proving to developers that the
> bug exists. Thanks.

Sorry again. Anyway, to be honest, I didn't see much in your initial
description in addition to the bug I closed it as a duplicate of.

With the additional info above: Can you explicitly mention what of the
described behaviour you exactly to consider to be a bug? I think it might help
to later split things into separate bug reports if you think that there's
multiple issues, but let's first try to make sure there's a common
understanding.

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