В чём проблема: большинство PDF* свёрстаны под печатную страницу формата A4 (29,7×21 см) или Letter, с полями, колонтитулами, всё как положено. А типичный экран читалки — 12×9 см с разрешением 800×600 точек. Даже если показывать по половине странице, на страницу приходится всего 1200×800 точек (и 18×12 см площади экрана). Значит, даже при просмотре страниц «половинками» буквы будут примерно в 1,65 раза мельче, вдобавок и разрешение при этом будет тоже как минимум раза в полтора ниже. Короче говоря, значительная доля PDF, свёрстанных под печать, на нынешних электронных читалка нечитаема.
Впрочем, во многих случаях можно легко из обычного PDF сделать PDF, легко читаемый на экране читалки. Дело в том, что значительную часть площади страницы обычно занимают поля. Они нужны для бумажной версии, но без них вполне можно обойтись на электронной читалке. И если обрезать поля (а в некоторых случаях можно обрезать и колонтитулы), то часто содержательная часть страницы будет выглядеть вполне читаемой и на маленьком экране читалки.
На сегодняшний день я нашёл и попробовал три способа обрезать поля у PDF-файла.
1. Обрезка полей с помощью pdfcrop
Есть скрипт
pdfcrop на перле (не путать с одноимённым скриптом на питоне), который умеет обрезать поля автоматически. В Debian он входит в состав пакета texlive-extra-utils.Использовать так:
$ pdfcrop --clip --margin 5 исходный.pdf обрезанный.pdf
Советую всегда всё равно оставлять небольшое поле (
--margin 5), иначе касающиеся края буквы могут не отображаться на экране читалки.В общем, всё просто. Преимущества: простой автоматический способ, по полученному таким способом PDF сохраняется возможность поиска. Недостатки такого способа:
pdfcrop очень медленно работает с большими документами (сотни страниц), нельзя автоматически отрезать колонтитулы и заметки на полях (в некоторых случаях проще обойтись без номеров страниц и названия главы сверху, зато получить более крупное изображение основного текста), конкретно моя читалка иногда аварийно перегружается на полученных таким способом PDF, на некоторых файлах pdfcrop неправильно определяет границы текста, на некоторых портит шрифты.2. Растеризация и обрезка страниц в ImageMagick
Пару раз мне пришлось прибегнуть к написанию самодельного скрипта, заточенного под определённый исходный PDF. Общая схема такая:
Исходный PDF → растеризованные изображения страниц (использую
pdftoppm) → разрезание страниц на части и обрезка полей (использую convert из ImageMagick) → сборка нового PDF или DjVu из обрезанных страниц.Вот пример такого скрипта, которым пользуюсь (он не только позволяет разрезать страницы на несколько колонок, но также отрезать поля и пережать, отбросив пустые страницы) — pdf-trim-to-djvu:
Как пользоваться — должно быть ясно из его справки:
Usage: pdf-trim-to-djvu [options] document.pdf
Options:
-fthe first page to process [default: 1]
-tthe last page to process
-dresolution in DPI [default: 150]
-c|--columnsmulti-column mode [default: 1]
--mono bitonal compression (black and white only)
--gray DjVuPhoto compression (shades of gray images) [default]
--color DjVuPhoto compression (color images)
-h|--help print this message
Автоматическая обрезка полей довольно хорошо реализована в команде
-trim ImageMagick, но можно задать параметры обрезки и вручную (приходилось). Например, чтобы принудительно обрезать по 3% с каждой стороны, в опции convert можно вставить -shave 3%x3% +repage.Если хочется не DjVu, а именно PDF, то собрать из изображений PDF можно так (о создании PDF с помощью IM см. здесь):
convert -define pdf:use-trimbox=true `ls -v *.ppm` -density разрешение_в_dpi книжка.pdfЕсли страниц много, такой способ будет очень медленным (и прожорливым), лучше конвертировать каждую отдельно (можно тем же
convert, если качество устраивает, можно специально для этих целей предназначенным sam2p), а потом объединять страницы вместе. Для объединения PDF-страниц в PDF-документ я использую pdftk: $ pdftk *.pdf cat output книжка.pdf
Преимущества этого способа: можно разрезать и обрезать страницы именно так, как надо. Недостатки: возможность поиска по тексту безвозвратно теряется, размер файла обычно увеличивается, добиться нормальной растеризации шрифта трудно, ну и сам скрипт иногда приходится менять под конкретную книжку.
3. Изменение границ страницы в PDFedit
Наконец, есть ещё способ. Совмещающий и возможность указать вручную что именно следует отрезать, и сохраняющий PDF в почти исходном виде. Есть редактор для PDF-файлов — PDFedit. Однако хотя эта программа и с графическим интерфейсом, методы всё те же.

Порядок действий:
- открываем копию PDF-файла в PDFedit и выбираем страницу, целиком заполненную текстом, чтобы было видно его границы;
- засекаем примерные численные координаты углов прямоугольника обрезки;
- в меню «Страница» выбираем «Изменить метрики страницы»; далее вводим новые параметры страницы цифрами, жмём «Изменить», чтобы проверить результат (такой вот GUI; что от чего отмеряется придётся познать на опыте), подобрав параметры страницы применяем обрезку ко всем с 1 по последнюю;
- сохраняем результат.
Преимущества: способ быстрый (даже если в документе несколько сотен страниц), возможность поиска по тексту сохраняется (да и вообще всё сохраняется), можно как угодно отрезать заметки на полях, номера страниц и колонтитулы. Недостатки: способ требует ручного подбора параметров, нельзя вырезать две страницы из одной (может можно, если дублировать страницы?), сам редактор PDFedit далеко не прост и полон сюрпризов.

* Вот, кстати, не пойму. Современные научные статьи распространяются почти исключительно в электронном виде (бумажные отпечатки — сувениры для авторов). За каждую операцию копирования файла издатели стараются взымать по 30 долларов (думаю, не бедствуют), а вот набирают статьи зачастую таким скупым кеглем, словно свою бумагу жалко. Сравните публикации XIX века и нынешнего. Отчего?



"* Вот, кстати, не пойму. ..."
ОтветитьУдалитьБумажные экземпляры журналов распространяются. Они попадают в библиотеки и активно заказываются, а также в журнальные фонды на сохранение. Шрифт мелкий, так как количество статей растет постоянно, не смотря на все старания рецензентов, среди которых и я ;) Ежегодно выходят журналы с тысячами страниц текста. К примеру, Physica Status Solidi и Journal of Crystal Growth выходят в год объемом примерно 5 и более тысяч страниц. Журнал Physical Review B вообще бьет все рекорды - страницы исчисляются десятками и сотнями(!) тысяч. Например, еще в далеком 2004 году моя статья в нем была опубликована на странице 235203. Это при том, что внутри статей нумерация страниц своя вида 235203-1, 235203-2 и т.д.. Следующаяя статья опубликована на 235204. То есть 235203 и 235204 - это еще и порядковый номер статьи среди опубликованных в текущем томе, состоящем из отдельных выпусков. В год выходит от одного до нескольких томов в зависимости от количества публикаций и политики издательства. Так что, если не жаться "словно свою бумагу жалку", то тома надо будет возить грузовиками :)
Поэтому я и говорю «почти». Бумажные экземпляры, конечно, есть, они уходят в какие-то библиотеки на сохранение, их даже кому-то присылают, но все, кто их заказывает — платят за бумажные экземплеря сполна (где-то мне попадалась цифра, что, однако, даже среди их получателей-людей только 3% читает их целиком). На практике же я вижу, что подавляющее большинство людей-читателей предпочитает скачивать и печатать PDF нужной статьи сами. То есть в любом случае, стоимость печати ложиться на читателей. И читается-печатается в любом случае только малая часть.
ОтветитьУдалитьПри этом, по данным библиотекарей ещё в лохматом 2002 году более 70% прочтений приходилось на электронные версии. Сейчас, думаю, больше.
Почему читатели должны при этом ломать глаза — мне не понятно. По-моему, это просто жадность издателей (помимо нежелания сверстать отдельно под экран или офисный принтер).
Мне кажется, что к издательствам банально таких пожеланий и претензий на шрифт не поступало. Например, у моих коллег и у меня никогда не было проблем с чтением статей из-за их шрифта. Нам даже удобно, что печать экономная:
ОтветитьУдалить1. бумага дорогая и в масштабах лабораторий/отделов это существенно оказывается - нас много печатающих много.
2. экологическая экономия поощряется, особенно зарубежом.
3. я каждый день вожу 10-к статей с собой (жаль 2 часа в метро терять просто так + нужны и на работе и дома) и мне удобнее возить листиков 20-30, чем 40-50 :) И так многие мои коллеги.
4. Представляющие важность статьи собираются в папки в общую внутреннюю библиотеку. На статьях мы делаем пометки еще. Количество шкафов и папок прямо зависит от объема распечаток :)
А вообще, на мой взгляд, не сложно сделать систему генерации pdf статей "на лету", как на xxx.lanl.gov. У зарубежных издательств она и так автоматическая. В таком случае можно генерировать с учетом пожеланий пользователя сайта pdf-ки, например касательно шрифта.
Ну да, насчёт экономии бумаги и веса вы правы. По две страницы на страницу с двух сторон я тоже печатаю :) Осталось перейти на газетную бумагу. Но из крупного текста сделать мелкий легко, а наоборот — трудно. Я же ещё горюю из-за отсутствия версий для устройств с низким разрешением (чтобы как раз в некоторых случаях вообще не печатать).
ОтветитьУдалитьСпасибо за комментарии.
\documentclass{article}
ОтветитьУдалить\usepackage[]{geometry}
\usepackage{pdfpages}
\begin{document}
\includepdf[noautoscale,fitpaper=false,pages=-,offset=]{source.pdf}
\end{document}
% so, you can place source.pdf's pages onto dest.pdf's pages with pdflatex .)
Отличный скрипт (pdf-trim-to-djvu). Очень и очень актуальный на сегодяшнее время. Весьма желательно сделать следующие дополнения к нему:
ОтветитьУдалить1. Скрипт на входе должен принимать не только pdf но и djvu файлы (для разборки вместо pdftoppm можно соответсвенно использовать ddjvu).
2. Подавляющее число читалок ч/б, как вариант для pdf, djvu, etc -файлов используются 4 или больше (но реже) градации серого --> очень желательна новая опция по умолчанию MODE=gray...
3. Учитывая тот факт, что многие pdf, djvu файлы содержат одновременно различные страницы: mono, gray, color (иногда с различным разрешением), желательно
разложить исходный файл на отдельные страницы {pdftk in.pdf burst} (попутно получаем файл с метеданными-pdf в doc_data.txt)-->
произвести предварительную проверку соотвествующих характеристик страниц, например, с помощью identify (imageMagic) -->
раскладывать на соответсвующие файлы (*.ppm - color, *.pgm -gray, *.pbm - mono) {pdftoppm} (хотя для портативных читалок цветные странцы вряд ли актуальны) -->
преобразование каждой отдельной страницы в djvu (соответтсвенным способом, зависящим от mono/grey/color) -->
сборка общего djvu -файла {djvm -c ebook.djvu *.djvu}.
Использование же только одной опции (mono or color) приводит либо к значительной потере качества отдельных страниц либо к необоснованному росту объема файла (все mono данные предствленны как color).
4. Как высший пилотаж - перенос оглавления во вновь собираемый файл. Пока настояший скрипт эту информацию удаляет. {pdftk in.pdf dumpdata metafile.txt | pdftk in.pdf burst --> doc_data.txt } -->
преобразуем (парсим) doc_data.txt в приемлемый для djvu файл bookmarks.txt типа:
(bookmarks
("Title" "#1")
("My Chapter 1" "#5"
("Sub Chapter 1" "#5")
("Sub Chapter 2" "#15"))
)
-->
добавляем оглавление в djvu {djvused file.djvu -e 'set-outline bookmarks.txt' -s} см. http://ubuntuforums.org/showthread.php?t=1522901
По крайней мере, у читалки PocketBook 902 возникает соответсвующее оглавление, подобное, как в pdf-файлах. Очень удобно.
При желании можно и др. метаинформацию перенести...
5. Если Вы будете поддерживать развитие этого скрипта в дальнейшем, желательно указывать в нем версию и дату.
Пределу совершенства нет... Читающая публика ждет от Вас следующего релиза!
Здорово. Вот уж не думал, что кто-то действительно пользуется моим скриптом.
ОтветитьУдалить1. Согласен. Думал над этим, но руки сделать не дошли.
2. У c44 есть опция монохромного сжатия, -crcbnone, но я с ней не экспериментировал. Количество градаций цвета там задавать нельзя. Для себя делаю почти всегда ч/б с разрешением побольше.
3. Идея хорошая. Только сейчас весь файл целиком не раскладывается, а обрабатывается постранично; иначе уж слишком много места на диске надо, чтобы большие книжки обрабатывать.
4. Идея с оглавлением мне нравится. Не знаю, поддерживается ли моей читалкой. Если да, можно попробовать.
5. Спасибо. Раз интерес есть, то, буду улучшать. Список обновлений можно видеть в https://bitbucket.org/jetxee/pdfscripts/changesets и там же текущую версию https://bitbucket.org/jetxee/pdfscripts/src/tip/pdf-trim-to-djvu — но за год там ничего не поменялось :-)
В своем скрипте Вы используете рабочую директорию в /tmp, т.е. в современных системах это RAM, поэтому беспокоитесь за объем...
ОтветитьУдалитьВ вашем случае разборка происходит по одной странцице --> в начале обработки имеем:
1 * IN + 1 * OUT; к концу обработки имеем 1 * IN + k * OUT страниц, где k - общее количество страниц в документе. Т.е. в максимуме k +1.
При пакетной обработке: в начале имеем k * IN + 1 * OUT, к концу те же 1 * IN + k * OUT, т.е. то же самое количество занятой памяти (k+1) IN/OUT-страниц.
Конечно, можно вспомнить о фрагментации памяти, неравенстве в объеме IN и OUT -страниц... Кроме того, о каких объемах pdf (djvu) файлов мы говорим - 2..70 мб.?
Но пакетная обработка один раз зачитывает исходный файл, все остальные операции делает в памяти (/tmp), сокращает число циклов в скрипте, позволяет в дальнейшем оценить качество каждой страницы (разложение --> анализ --> соответсвующее преобразование VS прямого несоответсвующего преобразования, как раз ведущего к увеличению OUT-file --> увеличение загрузки RAM (/tmp))...
Можно сделать и последовательную обработку, постраничную, это дело вкуса. Лишь бы сохранялся улучшенный алгоритм такой постраничной обработки...
Замена grayscale на mono + увеличение разрешения не на всех читалках может адекватно работать; потеря качества у картинок и бывших цветных диаграм очень значительная, вплоть до нечитабельной.
Вы как автор можете принимать или не принимать feedback, но народ все же ждет от Вас следующего релиза...
Постраничную обработку я сделал как раз, когда не хватило места в /tmp
ОтветитьУдалитьпри конвертации какой-то здоровой (порядка 1000 стр) книжки. Места
нужно много, потому что промежуточный формат — это несжатый PPM. Они
получаются довольно большие, порядка 2-10 мегапикселей в зависимости
от разрешения. Но в любом случае, и при постраничной обработке
цветность страниц определять можно.
2011/3/18 Disqus <>:
Пункт 1 (--gray) сделал. Вроде работает. Цветной текст в режиме --gray и разрешении 150 dpi выглядит в результате лучше, чем ч/б в разрешении 300, но по размеру больше. Размеры производимых файлов (первые пара страниц http://imwerden.de/pdf/platonov_dzhan.pdf):
ОтветитьУдалить84K color-150.djvu
200K color-300.djvu
64K gray-150.djvu
152K gray-300.djvu
24K mono-300.djvu
есть путь проще - напечатать в виртуальный принтер страницу в увеличенном масштабе
ОтветитьУдалитьЕсть прекрасная утилита как раз для образки полей.
ОтветитьУдалитьПреимущества:
1. Кроссплатформенная (написана на яве)
2. Есть GUI
3. Перед обрезкой накладывает все страницы документа друг на друга, что позволяет точно обрезать поля без случайно попавшего текста.
Называется Briss,
обзор здесь http://www.freewaregenius.com/2011/01/18/briss-crop-your-pdf-documents-using-a-visual-interface/
скачать здесь http://sourceforge.net/projects/briss/
используйте Скачать PDF-XChange Viewer Pro там уже встренна обрезка
ОтветитьУдалитьне годится, она только для Windows
ОтветитьУдалитьДобрый день. Не могли бы Вы описать как установить PDFedit. Заранее благодарен
ОтветитьУдалитьВ линуксе — обычно уже есть готовый дистрибутивный пакет (поискать по слову pdfedit в Ubuntu Software Center или аналогичной системе для своего дистрибутива). Версия для виндоус есть здесь: http://code.google.com/p/pdfeditor/downloads/list
ОтветитьУдалитьСсылки для скачивания исходников есть на сайте проекта: http://pdfedit.cz/en/download.html