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
What version of Okular are you using? 1.7.x has a scale mode chooser under the "PDF Options" tab in the print dialog.
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?
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.
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.
> 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.
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! ;-)
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)
Darn. That would be a good bug to file against Neon | Snaps.
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?
(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?
(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.
Ah perfect, I forgot that it was already committed!
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.
(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!
(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 ?
(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.