Bug 407998 - Okular scales down pages when printing
Summary: Okular scales down pages when printing
Status: RESOLVED WORKSFORME
Alias: None
Product: okular
Classification: Applications
Component: printing (show other bugs)
Version: 1.4.3
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-27 13:42 UTC by Sergio
Modified: 2020-03-30 08:18 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergio 2019-05-27 13:42:44 UTC
SUMMARY

Suppose you have a PDF document with A4 pages and that you want to print it to a printer using A4 paper. If you print via okular, the pages will be scaled down so that the whole of the original A4 page fits in the printable area of the printer. This is the same as the page scaling "fit to printable area" of acroread. Unfortunately, most of the time it is not what you want. In fact, the
original PDF document pages are quite likely to have their own margins.
Typically, you'll need page scaling "none", to assure that the printout is
identical to the source. For instance, this is fundamental if you are making
a printout where scale is important, such as a technical drawing, a map, the
text of an invoice to be printed over pre-printed paper, a letter where the
address should fall in the window of the envelope.

Ideally, okular should provide an option for the page scaling you want for
printing. Until this is possible, please at least refrain from scaling down
pages arbitrarly. In other word, do not scale down until the page fits in
the paper size regardless of the 'unprintable area' of the printer.


STEPS TO REPRODUCE
1. Open a pdf document with some element whose length is known (e.g. a box
   where you know the side length, a ruler, etc.)
2. Print it via okular

OBSERVED RESULT

Measure that length on the printout and see that it is shorter than it should


EXPECTED RESULT

Printing via okular should respect scale


As an additional note, observe that the scaling is correct if you print with
acroread 9
masterpdfeditor
or the plain lpr

SOFTWARE/OS VERSIONS
Linux/KDE Plasma
KDE Plasma Version: 5.15.4
KDE Frameworks Version: KDE Frameworks 5.54.0
Qt Version: 5.11.1
Comment 1 Nate Graham 2019-05-28 14:57:43 UTC
What version of Okular are you using? 1.7.x has a scale mode chooser under the "PDF Options" tab in the print dialog.
Comment 2 Sergio 2019-05-28 19:37:06 UTC
Cannot believe I posted all the versions of Qt, plasma, KDE framework and I forgot the version of okular! Sorry about that. 

It is 1.4.3, rather dated. Looks like ubuntu provides up to date plasma and framework via its KDE backports PPA, but does not provide fresh applications. Also kubuntu disco is still at 1.6.3.

So the question becomes: are the 1.4 and 1.6 series maintained upstream or downstream only? Is the newer scale mode chooser backportable by distribution? Alternatively would it be possible to at least disable the scaling in okular 1.4.x or 1.6.x when the PDF page size fits in the paper size (ignoring the printer margins) with a simple single patch that downstream can apply?
Comment 3 Nate Graham 2019-05-28 19:56:34 UTC
Those versions are not maintained or even developed upstream. KDE apps have a fairly short and frequent release schedule: three major versions a year, and each major version's bugfix branch is no longer maintained after the release of the next one.

It's not really ideal for LTS distros. :/ For those, you're better off using the Snap or Flatpak versions of apps if you find yourself in need of newer versions.
Comment 4 Sergio 2019-05-28 21:42:43 UTC
I was expecting something like that.

There is a lot of other software that has a similar development model and for them in many notable cases distros make the choice of "following the most recent stable" even if they are LTS or anyway non-rolling releases. A typical case is "firefox". I find it strange that they do not do so for KDE Applications. And I find it even weirder that Ubuntu does it (somehow) with its KDE PPAs for plasma and framework, but does not do it for applications.

Still, if a distro makes the choice of staying with an outdated version that is not updated upstream, that should mean providing some sort of downstream support. This is why I was asking if you expect my issue to be fixable with a simple patch downstream.
Comment 5 Nate Graham 2019-05-28 21:51:19 UTC
> I find it strange that they do not do so for KDE Applications
 I suspect that it's partially  a resourcing issue and partially because there's much less urgency compared to a web browser, which is the #1 attack vector on most computers.

> Still, if a distro makes the choice of staying with an outdated version that
> is not updated upstream, that should mean providing some sort of downstream
> support.
That's not really how it works. If distros choose to package old versions of our software, that doesn't (and shouldn't) create any kind of obligation on our part to provide patches. The IMO correct way to resolve this situation--if it needs resolving--would be to alter the KDE apps release model to have LTS releases like Plasma has. Then distros that insist on shipping old stuff can lock themselves into the LTS version of our apps and receive a steady stream of bugfixes, just like they do with Plasma.

Then again, this wouldn't help you since the scaling chooser was a new feature, not a bugfix--so you'd need a newer major version anyway.
Comment 6 Sergio 2019-05-28 22:43:06 UTC
On 28/05/19 23:51, Nate Graham wrote:
> https://bugs.kde.org/show_bug.cgi?id=407998
>
> --- Comment #5 from Nate Graham <nate@kde.org> ---
>> I find it strange that they do not do so for KDE Applications
>   I suspect that it's partially  a resourcing issue and partially because
> there's much less urgency compared to a web browser, which is the #1 attack
> vector on most computers.
I also tend to see it as a resourcing issue. But KDE Applications also happen to 
include a browser (konqueror) and an email client (kmail).
>> Still, if a distro makes the choice of staying with an outdated version that
>> is not updated upstream, that should mean providing some sort of downstream
>> support.
> That's not really how it works. If distros choose to package old versions of
> our software, that doesn't (and shouldn't) create any kind of obligation on our
> part to provide patches.

I know that there is no "obligation" from distros. I have not expressed myself 
correctly, sorry. What I meant is that if some user can find low risk patches 
for the unsupported version they ship (as I was trying to do), they should at 
least consider applying it downstream. For instance (with some resistance 
because of the SRU) they did when it was impossible to duplex.


> The IMO correct way to resolve this situation--if it
> needs resolving--would be to alter the KDE apps release model to have LTS
> releases like Plasma has. Then distros that insist on shipping old stuff can
> lock themselves into the LTS version of our apps and receive a steady stream of
> bugfixes, just like they do with Plasma.

> Then again, this wouldn't help you since the scaling chooser was a new feature,
> not a bugfix--so you'd need a newer major version anyway.
>
The scaling chooser is a new feature, but avoiding scaling something that should 
obviously not be scaled (and so avoiding the waste of a lot of ink and paper) 
looks more like a bugfix. So there is a chance that an LTS policy could still 
help!  In any case, right now, I am working around the issue using okular as a 
viewer and FoxitReader for Linux to print. Hope I'll not have to do it until 
Ubuntu 19.10! ;-)
Comment 7 Sergio 2019-05-29 16:26:16 UTC
Wanted to give 1.7.x a try and tried installing the snap. That does not work, though.


t.qpa.xcb: could not connect to display :0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Aborted (core dumped)
Comment 8 Nate Graham 2019-05-29 16:36:13 UTC
Darn. That would be a good bug to file against Neon | Snaps.
Comment 9 Sergio 2019-06-14 12:03:53 UTC
I have finally managed installing a recent version of okular (1.7.2). The operation of the scaling menu is a bit unclear to me, though.

1. It is presented as a PDF option, but okular supports many more formats. For instance, the option is absent for tiff, which is a nice multipage format for things like BW document scans with Group4 compression (even if those can certainly be embedded in PDF). Similarly, the option is absent for PNG, etc.

2. The option is grayed out unless I also activate "force rasterization" that makes each page take ages for printing.

3. The option seems to be unusable together with the print preview (e.g., it is impossible to use the option and preview the results /before/ printing).

Would it be possible to reconsider the way in which this otherwise useful option is proposed to the user?
Comment 10 Nate Graham 2019-06-14 16:18:14 UTC
(In reply to Sergio from comment #9)
> I have finally managed installing a recent version of okular (1.7.2). The
> operation of the scaling menu is a bit unclear to me, though.
> 
> 1. It is presented as a PDF option, but okular supports many more formats.
> For instance, the option is absent for tiff, which is a nice multipage
> format for things like BW document scans with Group4 compression (even if
> those can certainly be embedded in PDF). Similarly, the option is absent for
> PNG, etc.
It's being implemented for other file formats too. I can't find the patch right now but I know it's in progress!

> 2. The option is grayed out unless I also activate "force rasterization"
> that makes each page take ages for printing.
Already fixed in the next major Okular version with https://phabricator.kde.org/D18179

> 3. The option seems to be unusable together with the print preview (e.g., it
> is impossible to use the option and preview the results /before/ printing).
That seems like a legit issue. Ideally the print preview would actually be integrated into the Print dialog itself. Since the dialog comes from Qt, it would need to be fixed there. Here's the Qt bug tracking that: https://bugreports.qt.io/browse/QTBUG-57982

Looks like there is at least some movement on it. Once that's implemented, I would hope we can delete the Okular-specific Print Preview feature entirely! In the meantime it seems reasonable to request that the scaling feature be added to it. an you file a new bug to track just that?
Comment 11 Michael Weghorn 2019-06-15 19:34:28 UTC
(In reply to Nate Graham from comment #10)
> (In reply to Sergio from comment #9)
> > I have finally managed installing a recent version of okular (1.7.2). The
> > operation of the scaling menu is a bit unclear to me, though.
> > 
> > 1. It is presented as a PDF option, but okular supports many more formats.
> > For instance, the option is absent for tiff, which is a nice multipage
> > format for things like BW document scans with Group4 compression (even if
> > those can certainly be embedded in PDF). Similarly, the option is absent for
> > PNG, etc.
> It's being implemented for other file formats too. I can't find the patch
> right now but I know it's in progress!

This is https://phabricator.kde.org/D10974 and I quickly verified that current development version of Okular actually offers either "Fit to printable area" or "Fit to full page" when opening a TIFF file.
Comment 12 Nate Graham 2019-06-15 21:00:58 UTC
Ah perfect, I forgot that it was already committed!
Comment 13 Sergio 2019-07-01 20:17:54 UTC
Bad news: as of Okular 1.7.2 it is possible to require no scaling by also asking for rasterization, but unfortunately this causes the page to get printed with a significant offset to the right. Sending the page to the printer with lp does not cause the issue.

I do not know if this is already fixed given the progress that is being reported in this thread in the area.

Please let me know if I should open another bug for this issue.
Comment 14 Nate Graham 2019-07-07 20:59:53 UTC
(In reply to Sergio from comment #13)
> Bad news: as of Okular 1.7.2 it is possible to require no scaling by also
> asking for rasterization, but unfortunately this causes the page to get
> printed with a significant offset to the right. Sending the page to the
> printer with lp does not cause the issue.
> 
> I do not know if this is already fixed given the progress that is being
> reported in this thread in the area.
> 
> Please let me know if I should open another bug for this issue.
Does Bug 406053 or Bug 330820 describe your issue? If not, please open a new one. Thanks Sergio!
Comment 15 Éric Brunet 2020-01-14 21:40:05 UTC
(In reply to Michael Weghorn from comment #11)
> This is https://phabricator.kde.org/D10974 and I quickly verified that
> current development version of Okular actually offers either "Fit to
> printable area" or "Fit to full page" when opening a TIFF file.

This is very good indeed, but it seems to me a third option is needed:
     Keep the actual image size and do no scaling at all

At the moment, if I load a pdf of size 15cm x 8cm, I do not know how to print it to have a 15cm x 8cm picture in the middle of an empty A4 sheet of paper.

Or did I miss an option somewhere ?
Comment 16 Michael Weghorn 2020-03-30 08:18:00 UTC
(In reply to Éric Brunet from comment #15)
> (In reply to Michael Weghorn from comment #11)
> > This is https://phabricator.kde.org/D10974 and I quickly verified that
> > current development version of Okular actually offers either "Fit to
> > printable area" or "Fit to full page" when opening a TIFF file.
> 
> This is very good indeed, but it seems to me a third option is needed:
>      Keep the actual image size and do no scaling at all
> 
> At the moment, if I load a pdf of size 15cm x 8cm, I do not know how to
> print it to have a 15cm x 8cm picture in the middle of an empty A4 sheet of
> paper.
> 
> Or did I miss an option somewhere ?

At least in Okular 1.9.3, you can select this for the scale mode in the "PDF Options" tab: "None; print original size". It should do exactly what you want.