Преобразование PDF в JPG с помощью ImageMagick в PHP дает нечетное расстояние между буквами - PullRequest
Новая
       20

Преобразование PDF в JPG с помощью ImageMagick в PHP дает нечетное расстояние между буквами

4 голосов
/ 11 марта 2011

Я пытаюсь преобразовать PDF в JPG с помощью вызова PHP exec(), который выглядит следующим образом: 

convert page.pdf -resize 716x716 page.jpg

По какой-то причине JPG выходит с нестабильным текстом, несмотря на PDFвыглядит прекрасно в Acrobat и Mac Preview.Вот исходный PDF:

http://whit.info/dev/conversion/page.pdf

, а вот непредсказуемый вывод:

http://whit.info/dev/conversion/page.jpg

Сервер представляет собой стек LAMP сPHP 5 и ImageMagick 6.2.8.

Можете ли вы помочь этому тупому выродку?

Заранее спасибо,

Whit

Ответы [ 2 ]

4 голосов
/ 11 марта 2011

ImageMagick собирается обратиться к Ghostscript, чтобы преобразовать этот PDF-файл в изображение. Если вы запустите gs в pdf, вы получите тот же вывод с плохим интервалом.

Я подозреваю, что Ghostscript плохо обрабатывает встроенные в PDF шрифты TrueType. Если бы вы могли изменить вывод на встраивать шрифты типа 1 или использовать «основной» шрифт PostScript, вы получите лучшие результаты.

3 голосов
/ 12 марта 2011

Я подозреваю, что это проблема кодировки / ширины. И то и другое немного, хотя я не могу понять, почему.

Вот некоторые подозреваемые:

First

Текстовый поток определен в UTF-16 LE. charNULLcharNULL, используя обычный синтаксис команды рисования строк:

(some text) Tj

Есть способ экранировать любое старое символьное значение в строку (). Вы также можете определить строки в шестнадцатеричном виде следующим образом:

<203245> Tj

Ни один из методов не используется, только сомнительные встроенные нули. Это может вызвать проблему в GS, если он пытается работать с указателями на char без длины, связанной с ними.

Второй

Массив widths немой. Вы можете определить ширину в группах следующим образом:

[ 32 [450 525 500] 37 [600 250] 40 [0] ]

Это определяет
32: 450
33: 525
34: 500
37: 600
38: 250
40: 0

Эти шрифты определяют их последовательную ширину в отдельных массивах. Не незаконно, но определенно расточительно / глупо, и если GS был закодирован, чтобы ОЖИДАТЬ промежутки между массивами, это может вызвать ошибку.

В массиве также есть несколько очень подозрительных значений. С 32 по 126 определяются последовательно, но затем он начинает прыгать повсюду: ...126 [600] 8364 [500] 8216 [222] 402 [500] 8222 [389]. 8230 [1000] 8224 [444]... а затем снова становится последовательным со 160 до 255.

Просто странно.

Третий

Я даже не уверен в этом, но поток CIDToGIDMap содержит ОЧЕНЬ много нолей.

Итог

Эти шрифты рыбные. И я никогда не слышал о «Книгах колокольчика» или «UFPDF 0.1»

Этот номер версии заставляет меня съеживаться. Это должно заставить вас тоже съежиться.

Google для "UFPDF" Я нашел эту заметку от автора:

Примечание: я написал UFPDF как эксперимент, а не как готовый продукт. Если у вас есть проблемы с его использованием, не связывайтесь со мной за поддержку. Хотя патчи приветствуются, но у меня не так много времени, чтобы поддерживать это.

UFPDF - это библиотека PHP, которая располагается поверх FPDF. 0,1. Просто убегай.

...