Bug 339176

Summary: feature request: fit to page
Product: [Applications] okular Reporter: marco.morandini
Component: printingAssignee: Okular developers <okular-devel>
Status: CONFIRMED ---    
Severity: wishlist CC: aacid, auxsvr, b.weggenmann+kde, dollinger.florian, lagerimsi, m.weghorn, miranche, philippe, st.gruber, stanislav.horacek
Priority: NOR    
Version: 0.19.3   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:

Description marco.morandini 2014-09-18 13:53:28 UTC
This is a follow-up of bug #319476 : 

"it would be nice "to handle the case when the size of the pdf page is *smaller* than the printer page size. 

A fully functional "fit to printable area" feature would enlarge the text in this case, rather than leaving it default size with large margins. The shortcoming of this is best seen when printing 2 or more pages per sheet. This is a useful way of saving paper when the original document has a default page size smaller than the print paper size. 

At present, however, okular seems to first process the page for the specified paper size (say, US Letter), which leaves large margins around it, then shrinks it again to fit two or more pages into one. The result are very small letters and lots of unused white space.

Reproducible: Always
Comment 1 Albert Astals Cid 2014-09-18 18:43:41 UTC
Yeah, that'd be cool.
Comment 2 Miran B 2014-10-04 04:06:29 UTC
Agreed.  I've been thinking about reporting this for months.

Right now whenever I print multiple pages per sheet, I first need to manually enlarge the document using ghostscript.
Comment 3 lagerimsi 2014-12-04 15:30:35 UTC
also vote for this

My suggestion would be to have an option in the print dialogue to enable/disable "fit-to-page" (up- and downscale).

As we have https://bugs.kde.org/show_bug.cgi?id=336617 - this option would also satisfy people who don't want to use this option. In my opinion this should be enabled by default, as most of us will use it. People with special documents however should be able to disable it.

Workaround without using the CML for PDFs: open in GIMP or Firefox then print it :)
Comment 4 Christoph Feck 2015-03-15 19:05:12 UTC
*** Bug 343227 has been marked as a duplicate of this bug. ***
Comment 5 Florian Dollinger 2017-01-16 16:30:43 UTC
The problem is, that okular at first creates a PostScript File in /tmp/ named "okular_XXXXXX.ps". This File is then sent to the Printer using the lpr command.

That .ps file starts with something like that:

%Produced by poppler pdftops version: 0.50.0 (http://poppler.freedesktop.org)
%%Creator: org.apache.jsp._005fsize.margin_002dtest_005fpdf_jsp
%%Title: margin-test.pdf
%%LanguageLevel: 2
%%DocumentSuppliedResources: (atend)
%%DocumentMedia: A4 595 842 0 () ()
%%BoundingBox: 0 0 595 842
%%Pages: 1
%%PageMedia: A4
%%BeginResource: procset xpdf 3.00 0
%%Copyright: Copyright 1996-2011 Glyph & Cog, LLC

therefore, when the .ps file is sent to the printer - it is now recognized as A4 (e.g.) - even if it was a user-defined format before...

using the exact same lpr command (which includes the -o fit-to-page argument by default), and replacing the temporary .ps file with the original .pdf results in the desired print...

therefore the problem is that the page-layout for the print (e.g. A4) is already defined in the .ps file...
if you take a look at the sourcecode, you can find the /generators/poppler there, i guess if the option "-origpagesizes" for poppler would maybe fix that - at least for pdf's


voted +10 - that's really an important feature since many documents are non-standard-format
Comment 6 Florian Dollinger 2017-01-16 18:29:22 UTC
https://bugs.kde.org/show_bug.cgi?id=348172 and this one (https://bugs.kde.org/show_bug.cgi?id=339176) are possibly duplicates.
Comment 7 muzhit 2018-11-17 08:08:05 UTC
*** Bug 254306 has been marked as a duplicate of this bug. ***