pdf

Попалась задача — преобразовать огромный (полтора миллиона строк) тестовый файл в кодировке UTF-8 в PDF. Не ожидал с ней каких-то сложностей, но оказалось, что это не так-то просто.

Проблемы две — объём текста и кодировка. Графические утилиты на таком объёме умирают, а с кодировкой UTF, как оказалось, работают далеко не все утилиты командной строки.

Перебрал несколько, с задачей справилась только утилита paps. Хочу себе это записать, чтобы не пришлось заниматься перебором, если в будущем столкнусь с такой же задачей.

Ещё в моей задаче первый лист должен быть пустым и на каждом листе должен быть номер страницы. В результате строка запуска выглядит так:

paps --footer --footer-center={page_idx} <(printf \\f;cat listing.txt) -o listing.pdf

Небольшое примечание: при помощи printf я вставляю текстовый символ разрыва страницы (\f), чтобы первая страница оказалась пустой.

Четверть века назад я писал о «Думе», запущенном на фотоаппарате. Тогда меня это очень удивило и восхитило. Но с тех пор много времени утекло, «Дум» на чём только не запускали и это удивляло всё меньше. Не помню когда в последний раз, пробегая глазами подобную новость, я думал хотя бы «надо же».

Но «Дум», запущенный внутри PDF-файла, меня чертовски удивил! Не то, чтобы я не знал, что это возможно — в конце-концов, PDF сам по себе программный файл (там внутри язык программирования PostScript), но я как-то даже и не думал о такой возможности.

Вы попробуйте, работает даже внутри браузера!

Правда, в данном случае PostScript почти не использовался. Всё дело в том, что внутри PDF есть возможность использовать ещё и JavaScript. Причём, в случае Adobe Acrobat, доступны, например, такие, сомнительные для PDF возможности, как 3Д-графика или HTTP-запросы.

В просмотрщиках PDF современных браузеров поддержка JavaScript тоже есть, правда она сильно ограничена по функционалу. Тем не менее, для запуска «Дума» хватило и этого.

Чтобы запустить «Дум» внутри PDF, использовался старый Emscripten, который компилирует код на Си в asm.js (это такое подмножество JavaScript), вместо более привычного WebAssembly. Но этого недостаточно — нужно было придумать, как принимать ввод с клавиатуры и отображать графику. Это оказалось не таким уж и простым. К счастью, в браузерах PDF-движки поддерживают текстовые поля и кнопки, что и было использовано для ввода.

С графикой возникли следующие проблемы. Речь идет о разрешении 320×200 пикселей, что означает, что если бы использовались обычные текстовые поля для каждого пикселя, пришлось бы обновлять тысячи полей на каждый кадр. В общем, так бы вы никогда не поиграли в «Дум». Вместо этого автор решил использовать одно текстовое поле на каждую строку экрана и обновлять их с помощью ASCII-символов. Простой, но довольно эффективный способ, который дает в итоге монохромную картинку с шестью цветами. Конечно, такой способ тоже не даёт плавного рендера картинки, но играть всё равно довольно комфортно!

Переложил на хостинг «Гитхаба» свой проект семилетней давности — «Какие графические форматы поддерживает ваш браузер?». Я его иногда обновляю и мне было бы проще это делать через репозиторий.

Из всего, что я там проверяю, сразу не сработала только проверка на AVIF — это новейший формат, у меня на компьютере его поддерживает пока только «Файерфокс», ему важно указание типа содержимого, а «Гитхаб» передаёт неправильное значение.

Я подумал, что наверняка есть какой-то способ указать правильный тип в файле конфигурации сайта, но нет, так это не работает, такой настройки в нём нет. В принципе, известно откуда «Гитхаб» берёт свою базу типов содержимого — из проекта mime-db. Но этот путь тоже не сработал — я добавил туда тип для AVIF больше недели назад, но ничего не изменилось. Видимо синхронизация изменений происходит нечасто.

Пришлось идти другим путём — вместо того, чтобы загружать файл картинки, внедрил его внутрь при помощи протокола data:, это позволило обойти проблему. Можете протестировать на своём браузере.

Ссылка на проект: https://bolknote.github.io/detect-browser-graphics-formats/
Ссылка не репозиторий проекта: https://github.com/bolknote/detect-browser-graphics-formats

Многие, наверное, знают что у плагина Эдоуби для просмотра ПДФ есть специальные параметры, которые передаются фрагментом в урле. Эдоуби публиковала эти параметры в разных документах, а теперь они собраны в специальном ЭрЭфСи под номером 3778.

Я для интереса попробовал эти параметры в «Хроме» (там собственный просмотрщик, поэтому я не удивился бы, если бы они не сработали) и оказалось, что три из них всё же работают:

# увеличение на 50%
http://example.org/sample.pdf#zoom=50
# переход к странице №2
http://example.org/sample.pdf#page=2
# переход к главе «Chapter»
http://example.org/sample.pdf#nameddest=Chapter

Подробнее можно прочитать ЭрЭфСи (в частности, в «zoom» можно указать ещё два параметра). Так же параметры можно комбинировать, это тоже работает — если указать их через амперсанд.

Браузер «Сафари» под «Мак», оказывается, умеет отображать PDF (и TIFF, кстати, тоже) в теге IMG. Т. е. как простую картинку. Поскольку в OSX есть встроенная поддержка PDF, такое поведение браузера, видимо, вытекает из того, что картинки в браузере отображаются через какой-то системный компонент. Причём, с отображением PDF через тег OBJECT у «Сафари» есть проблемы, если только не установить специальный плагин от фирмы Adobe.

А вот браузер «Опера», помимо стандартного набора JPEG/PNG/GIF/XBM умеет отображать ещё и ICO. Почему этого не делают остальные браузеры — загадка, ведь им всё равно приходится работать с этим форматом, чтобы отобразить favicon.ico.

Если отослать на адрес pdf2html@adobe.com письмо с URL, указывающим на файл PDF, в теле письма, то этот файл автоматически сконвертируется в HTML и упадёт в ваш почтовый ящик уже через пару минут. Естественно, русские буквы преобразуются в симпатичные квадратики.