12

I'm not sure if this is a TeX related question at all or rather a general problem with Adobe reader, or Windows, or printer drivers, or whatever else is involved.

When I create PDF files with pdflatex in A4 paper size and print them to my A4 printer from Adobe reader, there are several options available for "Page scaling", such as "None", "Fit to printable area", and "Shrink to printable area". Since the document and paper size ar both A4, one might expect that all three options result in printout at original size, especially if there is a thick white margin and nothing interferes with technical printing problems at the paper boundary, say. However, the fit/shrink options both cause a scale factor of 94% and one has to be careful to select the "None" option in order to obtain correct output.

Minimal (with respect to pdf content) example:

\documentclass[a4paper]{article}
\begin{document}
\thispagestyle{empty}
\null
\end{document}

Is there any possibility to set something in my TeX files such that the pdf files produced are "aware" that there is enough white margin and that no 94% scaling is needed? (Alternatively, I might produce page sizes 6% smaller than A4, but would consider that counterproductive and ridiculuous)

  • 7
    I've always found really peculiar that Adobe Reader thinks A4 paper doesn't fit in A4 paper and wants to scale it down. I don't think it's a TeX and friends problem, but just Adobe's. – egreg Oct 6 '14 at 13:59
  • 7
    The 94% scaling is a function of your printer's margins. Adobe Reader sees an A4 (or US letter, or whatever) page size and wants to fit that page size into the printable area on the sheet (inside the margins). So if you know you have an A4 page with acceptable margins for the printer, just remove any scaling. – Mike Renfro Oct 6 '14 at 14:09
  • 1
    \usepackage{hyperref} \hypersetup{pdfprintscaling=None} – Thérèse Oct 6 '14 at 14:15
  • 1
    \hypersetup{pdfprintscaling=None} works fine for me: In the print dialog the "don't scale" option is then selected. – Ulrike Fischer Oct 6 '14 at 15:50
  • 1
    No, the option really change the default dialog. I tested it. And I don't know how the driver should notice that there is a margin: It doesn't look at the content. – Ulrike Fischer Oct 7 '14 at 10:40
3

If I run pdfinfo -box on a PDF file generated by pdftex, I get the following information:

Creator:        TeX
Producer:       pdfTeX-1.40.15
CreationDate:   Mon Oct  6 16:01:48 2014
ModDate:        Mon Oct  6 16:01:48 2014
Tagged:         no
Form:           none
Pages:          1
Encrypted:      no
Page size:      595.276 x 841.89 pts (A4) (rotated 0 degrees)
MediaBox:           0.00     0.00   595.28   841.89
CropBox:            0.00     0.00   595.28   841.89
BleedBox:           0.00     0.00   595.28   841.89
TrimBox:            0.00     0.00   595.28   841.89
ArtBox:             0.00     0.00   595.28   841.89
File size:      58874 bytes
Optimized:      no
PDF version:    1.5

When I check a PDF exported from TextEdit, I get

Title:          ***
Subject:        
Keywords:       
Author:         ***
Creator:        TextEdit
Producer:       Mac OS X 10.9.2 Quartz PDFContext
CreationDate:   Mon Oct  6 14:10:45 2014
ModDate:        Mon Oct  6 14:10:45 2014
Tagged:         no
Form:           none
Pages:          1
Encrypted:      no
Page size:      595 x 842 pts (A4) (rotated 0 degrees)
MediaBox:           0.00     0.00   595.00   842.00
CropBox:            0.00     0.00   595.00   842.00
BleedBox:           0.00     0.00   595.00   842.00
TrimBox:            0.00     0.00   595.00   842.00
ArtBox:             0.00     0.00   595.00   842.00
File size:      16393 bytes
Optimized:      no
PDF version:    1.3

The only possible problem might be the page width, which is 595.276 in the former case, 595 in the latter.

Now \pdfpagewidth is set to 597.50787pt, which corresponds to 595.27559bp and this explains the shown value of 595.276. If we convert this into millimeters, we get

597.50787*25.4/72.27 = 209.99999

but converting 595.276bp to millimeters gives

595.276*25.4/72 = 210.00014

I don't think that a surplus of less than 150nm (nanometers) should trigger a size reduction of 6% “to fit”. Even if 595.28 is used, we have

595.28*25.4/72 = 210.00156

but, again, a surplus of less than 2µm (micrometers) doesn't seem sufficient for pushing Adobe Reader into thinking that the page “doesn't fit”.

The conversion of 595bp into millimeters is

595*25.4/72 = 209.90278

which is short of 210mm by sligthly more than 0.04%, while 210.00156mm is about 0.001% more than 210mm.

Nothing will convince me that the computations made by Adobe Reader are so accurate that a difference of less than 0.001% forces shrinking.

  • Nice investigations, but behind all that I kind of lost the point of your answer. What exactly are these boxes and what does the output of pdfinfo tell us? Why do you compare to a PDF from TextEdit? Does it not show the weird behavior in AR? – Daniel Oct 6 '14 at 17:44
  • Intuitively, I would expect that at least one of the boxes should not start at '0.00 0.00', because of the margin. – Daniel Oct 6 '14 at 17:45
  • 1
    @Daniel Yes, a PDF originated by exporting instead of printing doesn't cause Adobe Reader to try shrinking. – egreg Oct 6 '14 at 17:47
  • 1
    @egreg Oh, interesting. So it seems it is possible to put the information that shrinking is a bad idea somewhere. Admittedly, I just tried the same with a pdf export (from Word 2010 under Windows 2008) and that showed the same 94% problem. Can you somehow upload an A4 pdf that does not wnat to shrink so that I can test it on my system? – Hagen von Eitzen Oct 7 '14 at 10:09
  • SOLUTION: tex.stackexchange.com/a/232718/4736 – Keks Dose Mar 12 '15 at 11:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.