This sounds like bug 348172, therefore I'm closing this as a duplicate.

https://phabricator.kde.org/D7962 added the possibility to select whether or not the document should be scaled to take into account hardware printer margins if the "Force rasterization" option is set in the printer dialog.

Please reopen if margins are still added when no scaling has explicitly been selected there.

(By the way, https://phabricator.kde.org/D18179 is supposed to make the same options available without having the "Force rasterization" checkbox enabled as well.)

*** This bug has been marked as a duplicate of bug 348172 ***

I do not have "Force rasterization" enabled. I don't even know where the scaling settings are.

Ah, sorry for not being more explicit. Bug 348172 has the "Version Fixed In" set to 19.04.0, i.e. you'll get that feature with the upcoming Okular version only.

The scaling options are just below the "Force rasterization" option (i.e. under "Options" -> "PDF Options" in the print dialog).

*** This bug has been marked as a duplicate of bug 348172 ***

Okay, thanks. I hope that fixes it.

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.

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

- On physical printers, Okular seems to ignore the paper size setting in the Printer Properties dialog.
- 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.

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.
- "Print original size" shifts the entire document down and to the right.

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.

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.

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

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!

Requested info has been provided in comment 7. I hope I'll find the time to answer sometime soon.

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

I filled an issue about that some years ago ...

In concrete terms, we cannot print a document using Okular if we need a 1:1 scale.

In other words, a user will get wrong dimensions if it prints a 10 cm square using Okular.

This issue doesn't happen if we print using the lpr command, but Evince has the same issue if we don't change the default setting so as to apply any scale adjustment  (i.e. tweak a parameter in a tab ...).

The right way is to implement printing as in Acroread !!!

(In reply to fabrice salvaire from comment #11)
> I filled an issue about that some years ago ...
> 
> In concrete terms, we cannot print a document using Okular if we need a 1:1
> scale.
> 
> In other words, a user will get wrong dimensions if it prints a 10 cm square
> using Okular.
> 
> This issue doesn't happen if we print using the lpr command, but Evince has
> the same issue if we don't change the default setting so as to apply any
> scale adjustment  (i.e. tweak a parameter in a tab ...).
> 
> The right way is to implement printing as in Acroread !!!

As mentioned above, Okular now allows to apply different options for scaling if you have a recent enough version. With regard to what option should be selected by default, that can for sure be discussed...


@Matthew: Any more comments/ideas on comment 10? Otherwise, if there's a common understanding, I'd suggest to continue the single aspects in separate new bug reports as needed.

I've opened separate bug reports.

https://bugs.kde.org/show_bug.cgi?id=408270
https://bugs.kde.org/show_bug.cgi?id=408271
https://bugs.kde.org/show_bug.cgi?id=408272
https://bugs.kde.org/show_bug.cgi?id=408273

(In reply to Matthew Trescott from comment #13)
> I've opened separate bug reports.
> 
> https://bugs.kde.org/show_bug.cgi?id=408270
> https://bugs.kde.org/show_bug.cgi?id=408271
> https://bugs.kde.org/show_bug.cgi?id=408272
> https://bugs.kde.org/show_bug.cgi?id=408273

Thanks! Closing this one then.

*** This bug has been marked as a duplicate of bug 408270 ***