2

I have this PDF file created by scanning. When viewing it in any PDF viewer, the page's width is greater than the height.

But it seems like all the PDF applications I have tried mistake the width as the height and the height as the width for this PDF file (see below.)

Why?

Is the PDF file broken?

How can I "repair" the PDF file so that the PDF applications don't mix its width and height?

  1. The following command shows the width is smaller than the height in points:

    $ pdfinfo test.pdf 
    Creator:        Xerox WorkCentre 7830
    Producer:       Xerox WorkCentre 7830
    CreationDate:   Tue Dec 23 00:22:47 2014
    Tagged:         no
    Form:           none
    Pages:          1
    Encrypted:      no
    Page size:      612 x 1008 pts
    Page rot:       90
    File size:      81820 bytes
    Optimized:      no
    PDF version:    1.4
    
  2. The following command shows the width is smaller than the height in pixels:

    $ pdfimages -list test.pdf 
    page   num  type   width height color comp bpc  enc interp  object ID
    ---------------------------------------------------------------------
       1     0 image     864  1400  rgb     3   8  jpeg   no         6  0
       1     1 mask     1236   895  -       1   1  jbig2  no         8  0
       1     2 mask      737   891  -       1   1  jbig2  no        10  0
       1     3 mask      247   381  -       1   1  jbig2  no        11  0
       1     4 mask       44   298  -       1   1  jbig2  no        12  0
       1     5 mask      429     9  -       1   1  jbig2  no        13  0
       1     6 mask       22   258  -       1   1  jbig2  no        14  0
       1     7 mask      130   142  -       1   1  jbig2  no        15  0
    
  3. I am trying to crop away the left and right margins of the PDF file, using the script pdfcrop.sh here which seems based on gs and pdftk. My measurements of the left and right margins are 116 pts and 20 pts.

    The usage of the script says:

      echo " -t \"<left> [<top> [<right> <bottom>]]\""
      echo "    trims outer page edges by the given amounts. Unit is bp. A single number"
      echo "    is used for all trims, two numbers \"<left> <top>\" are applied to the"
      echo "    right and bottom trims alike."
    

    but

    pdfcrop.sh -t "116 0 20 0" test.pdf trimmed.pdf

    will crop the top by 116 pts and the bottom by 20 pts, while the following does the correct thing by crop the left by 116 pts and the right by 20 pts.

    pdfcrop.sh -t "0 116 0 20" test.pdf trimmed.pdf

1

0.

Here is a PNG made from your one page sample PDF file:

test.png (converted from test.pdf)

1.

When viewing it in any PDF viewer, the page's width is greater than the height.

This is exactly as it's supposed to be.

2.

[...] it seems like all the PDF applications I have tried mistake the width as the height and the height as the width for this PDF file.

As you said, it only seems like that.

3.

Is the PDF file broken?

No, it isn't.

4.

You overlooked one information which your first command (pdfinfo) gave you:

Page rot:       90

It means that the PDF source code inside the PDF file tells the viewer to take this "It's indeed higher than wide"-page and display it with a 90 degree rotation.

Thus, "viewing it in any PDF viewer, the page's width is greater than the height". As it is supposed to be. See my No. 1 above. And my No. 2 above.

5.

You can use pdfimages to extract all images, and then ImageMagick's convert to convert these which do come out as PNM or PBM to JPEG:

 pdfimages -j test.pdf test-

 for i in *.pbm ; do            \
    convert $i ${i/.pbm/.jpg} ; \
 done

This results in eight different images, the ones with numbering 0--7 in your pdfimages -list command from your question ('2.').

Here are these images. All of them are scaled to 25% of their original size so not too much space is wasted. All of them are displayed in their "natural" orientation, as they are extracted by pdfimages. Here is the first one, number 0 in your list:

This image was extracted in its "natural" orientation. It is clearly higher than wide.

The following pairs of images are all scaled by 25%. They represent images of type mask in the list of your pdfimages output above:

   

  

Your scanner (with its built-in software) is a more "intelligent" one. It does not simply make a single TIFF from the page and then embed that into a PDF shell, but it tries to optimize the different parts, using image 'masks' (with alpha channels -- appearing as black colors in the JPEGs I created) for parts which contain text.

Luckily, your scanner software was not "more" intelligent when it applied its compression for the text, and it used JPEG2000 instead of JBIG2. So you did not fall for the infamous "Xerox scanning bug".

16
  • Thanks. (1) what do you mean by "your scanner software was not "more" intelligent when it applied its compression for the text, and it used JPEG2000 instead of JBIG2. So you did not fall for the infamous Xerox scanning bug"? (2) how can I actually rotate a pdf file, so that "Page rot" is 0? (I tried pdftk in.pdf cat 1-endW output out.pdf, and the input and output pdf files' images have the same width by height size, but different "Page rot"). – Tim Jan 28 '15 at 23:13
  • About (2), (1) "not the two blanks now!" or "note the two blanks now!"? (2) Why "Don't change the number of bytes!"? Even that means we have to do meaningless things? Can that be overcome? (2) My intention is to get a pdf file with /Rotate 0 but still viewed the same as the original pdf file with /Rotate 90 – Tim Jan 28 '15 at 23:47
  • @Tim: (1) Follow my links; read/watch whatever you find there. (2) Replace /Rotate 90 in the PDF file wherever you find it by /Rotate 0 (note the two blanks now!, Don't change the number of bytes!). -- Be aware that when you do so, the page content may be rotated off the page canvas, in toto or in parts... – – Kurt Pfeifle Jan 29 '15 at 0:01
  • @Tim: No. of bytes: Two reasons. (1) A PDF has a kind of ToC, normally at its end. The keyword is xref (for cross reference table). The Xref table lists all PDF objects with their respective byte offsets. (2) Many objects contain streams. When that's the case, their /Length (keyword!) has to be noted. -- So, when changing number of bytes you may inadvertedly corrupt xref and/or /Length values. – Kurt Pfeifle Jan 29 '15 at 0:06
  • @Tim: it is totally stupid and meaningless to try and intend "to get a pdf file with /Rotate 0 but still viewed the same as the original pdf file with /Rotate 90". -- Pardon my French! – Kurt Pfeifle Jan 29 '15 at 0:08

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.