Bug 440117

Summary: Option for scaling the printed image
Product: [Frameworks and Libraries] print-manager Reporter: pietz
Component: generalAssignee: Daniel Nicoletti <dantti12>
Status: RESOLVED DOWNSTREAM    
Severity: normal CC: nate
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Kubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description pietz 2021-07-21 16:13:59 UTC 
My issue:
I have a borderless PDF file. The problem is that KDE shrinks the PDF to fit the printable area of the Pinter. This produces a smaller scaled output.

In the printing dialog (I printed from Okular) I can also NOT reduce the borders. The minimum in my case is 4,23mm on each edge.

It would be nice to tell the dialog somehow to scale the source or/and reduce the borders to 0mm. The printer will "protect" itself anyways and cannot print to the real edge. But then the output will be in original scale. Only edges are cut.

On my MacBook I can choose those options (scale to 100%) and it works as expected. So it should not be a problem of my printer or CUPS because Apple also uses CUPS.

Thanks
Andreas
Comment 1 Nate Graham 2021-08-04 19:18:23 UTC 
This is something that needs to be implemented in the app itself; it cannot be done centrally. Luckily for yo, Okular actually does have options for this in its print dialog. Unhelpfully for yo, they only work if you check the "Force Rasterization" checkbox, which is a terrible UX. Nonetheless, it should work, and we will fix the UX issue.
Comment 2 pietz 2021-08-05 08:37:53 UTC 
But why does it work in MacOS then in a central way and independent from any app? Mac also uses CUPS and their printer dialog scales the complete page bigger or smaller. I don't understand why this should be done in the app and not by the printer dialog…
Comment 3 Nate Graham 2021-08-06 18:12:02 UTC 
It's a matter of expectations and software architecture. macOS has a centralized print dialog that implements all of these kinds of options in it so that apps don't have to. In the KDE world, we use the Qt print dialog which does not implement all of these options. As a result, over the years apps have made their own homegrown implementations of these features which would conflict with a central implementation, were it to be created.

If you want the Qt print dialog to be more like the feature-filled macOS print dialog, that would need to be done by the Qt folks, not us. As a part of this, they would need to come up with a process of handling conflicts between the dialog's implementation of features such as scaling vs the app's own implementation. It's a tricky thing. In my opinion, macOS got it right by investing in a feature-filled print dialog from the start, which limited the amount of work that 3rd-party developers had to do to add features that users expect. like scaling.