Все приложения PDF смешивают ширину и высоту PDF-файла

У меня есть этот файл PDF, созданный при сканировании. При просмотре в любом приложении просмотра PDF ширина страницы больше высоты.

Но похоже, что все приложения PDF, которые я пробовал, ошибочно принимают ширину, как высоту и высоту, так и ширину для этого файла PDF (см. Ниже).

Зачем?

Не поврежден ли файл PDF?

Как я могу «восстановить» файл PDF, чтобы приложения PDF не смешивали его ширину и высоту?

  1. Следующая команда показывает, что ширина меньше высоты в точках:

    $ 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. Следующая команда показывает, что ширина меньше высоты в пикселях:

     $ 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. Я пытаюсь обрезать левый и правый поля PDF-файла, используя здесь скрипт pdfcrop.sh который, похоже, основан на gs и pdftk . Мои измерения левого и правого полей – 116 очков и 20 очков.

    Использование сценария гласит:

      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." 

    но

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

    будет обрезать вершину на 116 очков, а нижняя – на 20 очков, в то время как следующее делает правильную вещь, урожая слева на 116 очков и право на 20 очков.

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

0.

Вот PNG, сделанный из файла PDF с одной страницей:

test.png (преобразованный из test.pdf)

1.

При просмотре в любом приложении просмотра PDF ширина страницы больше высоты.

Это точно так, как должно быть.

2.

[…] Кажется, что все приложения PDF, которые я пробовал, ошибочно принимают ширину как высоту и высоту как ширину для этого файла PDF.

Как вы сказали, это только кажется .

3.

Не поврежден ли файл PDF?

Нет, это не так.

4.

Вы упускаете из виду одну информацию, предоставленную вашей первой командой ( pdfinfo ):

 Page rot: 90 

Это означает, что исходный код PDF внутри PDF-файла говорит, что зритель воспринимает это «Он действительно выше, чем широкий» -страница и отображает его с вращением на 90 градусов.

Таким образом, «просмотр его в любом приложении просмотра PDF, ширина страницы больше высоты» . Как и предполагалось. См. Мой № 1 выше. И мой № 2 выше.

5.

Вы можете использовать pdfimages для извлечения всех изображений, а затем convert ImageMagick, чтобы преобразовать их, которые выходят как PNM или PBM в JPEG:

  pdfimages -j test.pdf test- for i in *.pbm ; do \ convert $i ${i/.pbm/.jpg} ; \ done 

Это приводит к восьми различным изображениям: номера нумерации 0–7 в вашей pdfimages -list из вашего вопроса ( «2.» ).

Вот эти изображения. Все они масштабируются до 25% от их первоначального размера, поэтому не слишком много места тратится впустую. Все они отображаются в их «естественной» ориентации, так как они извлекаются pdfimages . Вот первый, номер 0 в вашем списке:

Это изображение было извлечено в его «естественной» ориентации. Он явно выше, чем широкий.

Следующие пары изображений масштабируются на 25%. Они представляют изображения mask типа в списке ваших pdfimages выше:

Ваш сканер (со встроенным программным обеспечением) является более «интеллектуальным». Это не просто делает один TIFF со страницы, а затем встраивается в оболочку PDF, но он пытается оптимизировать разные части, используя маски изображения (с альфа-каналами – появляющимися как черные цвета в созданных мной JPEG) для частей, содержащих текст.

К счастью, ваше программное обеспечение сканера не было более « интеллектуальным», когда оно применяло сжатие для текста, и вместо него использовалось JPEG2000 вместо JBIG2. Таким образом, вы не попали на печально известную « ошибку сканирования Xerox » .