404 - Unable to load website

uCoz Error 404

SITE NOT FOUND

The website "djvu-soft.narod.ru." is not registered with uCoz.
If you are absolutely sure your website must be here,
please contact our Support Team.
If you were searching for something on the Internet and ended up here, try again:

About uCoz web-service

Community

Contacts

Legal information

Книгосканирование и формат PDF

Вернуться к разделу "Материалы по сканированию и оцифровке бумажных книг".

Книгосканирование и формат PDF

Для создания электронных версий бумажных книг нередко используется формат Pdf. Особенно это характерно для западных электронных книг.

Формат Pdf, на взгляд многих людей, значительно уступает формату DjVu - как средство создания скан-книг. По этому вопросу до сих пор ведутся ожесточённые споры на тему "Какой формат лучше для электронных книг - Pdf или DjVu?".

В этой статье я делаю попытку раскрыть этот вопрос более подробно - но, по-возможности, без "залезания в дебри" и без повторения общеизвестных истин об свойствах этих двух форматов. А также мы рассмотрим основные моменты, относящиеся к использованию формата Pdf для нужд сканирования книг.

"Каноническое" сравнение форматов DjVu и Pdf

На сайте DjVu.org есть несколько статей, напрямую сравнивающих форматы Pdf и DjVu:

Slides From A Talk Comparing Djvu To Other Formats

DjVu Compression Ratios Compared To Other Formats

DjVu-Digital vs. "Super Hero" PDF

Основные преимущества и недостатки 2 форматов

1. Формат PDF стандартизован организацией ISO (International Organization for Standardization). Формат DjVu - нет.

2. Формат DjVu практически не предоставляет сторонним разработчикам бесплатного программного инструмента для чтения и мета-редактирования DjVu-файлов, которое можно было бы интегрировать в свои коммерческие приложения. Это сильно сдерживает развитие формата (например, он не индексируется Google). Для коммерческого использования есть только 2 официальных варианта: платный Celartem Imaging SDK for DjVu v1.0 и бесплатное, но неудобное средство - ActiveX Control в броузерном DjVu-плагине. Вот условия их использования:

The "LizardTech Computer Software License Agreement" includes an overview of the licensing process. In brief, you can evaluate either SDK for free by executing the license and faxing it back to us (fax: +1 206 652 0880, "Subject: DjVu SDK Evaluation Agreement"). To make productive use of an SDK, you must enter into a commercial agreement with Lizardtech which involves a licensing fee of $6495 and royalty payments (if applicable, typically a quarterly fee either fixed or a fraction of your product revenue). The first year's support fee is included with the initial licensing fee. Thereafter support is $1,195 per year. To expedite the evaluation request, please be sure to specify which library and which development platform (e.g. win32-MSVC8, linux-gcc3.4).

** Important note for those interested in developing Win32 viewing applications.

For most win32-based viewing applications, a simple and economical (free) alternative to an SDK is to host the DjVu Viewer ActiveX control (which ships as part of the browser plugin -- available as a free download from the LT web site). As with the SDK, support contracts are available.

3. Формат Pdf значительно более популярен в мире, нежели чем формат DjVu (который на Западе почти неизвестен).

Сравнение Pdf и DjVu для случая чёрно-белых изображений

Сравнивая форматы DjVu и Pdf по уровню сжатия, для случая чёрно-белых изображений имеет смысл сопоставить алгоритмы сжатия JB2 и JBIG2, первый из которых применяется в DjVu, а второй - в Pdf.

Изначально для сжатия чёрно-белых изображений существовали форматы Huffman RLE, CCIT FAX G3 и CCIT FAX G4. Потом появился JBIG (1993), который был позже переименован в JBIG1. Но он не получил широкого распространения. Затем появился JBIG2, и он был был опубликован в 2000 как международный стандарт ITU T.88 и в 2001 как ISO/IEC 14492.

Начиная с 1996 года, появился формат DjVu, в котором был реализован JB2 - этот формат сжатия разработала AT&T в ответ на создание JBIG2 (и как его аналог).

В настоящее время форматом JBIG2 владеет CVision, а форматом JB2 - LizardTech. Кроме того, JBIG2-сжатие в настоящее время интегрировано в программы от Adobe и используется при создании и чтении Pdf-файлов.

Вот выдержка из статьи High Quality Document Image Compression with DjVu, описывающая формат JB2:

(Раздел Technical Papers on DjVu Technology на сайте LizardTech)

4.1 Coding the Bi-Level Mask Using JB2

The bi-level image compression algorithm used by DjVu to encode the mask is dubbed JB2. It is a variation on AT&T's proposal to the upcoming JBIG2 standard for fax and bi-level image compression. Although the JBIG1 [JBIG, 1993] bi-level image compression algorithm works quite well, it has become clear over the past few years that there is a need to provide better compression capabilities for both lossless and lossy compression of arbitrary scanned images (containing both text and half-tone images) with scanning resolutions from 100 to 800 dots per inch. This need was the basis for JB2. The key to the JB2 compression algorithm is a method for making use of the information found in previously encountered characters without risking the introduction of character substitution errors that is inherent in the use of Optical Character Recognition (OCR) [Ascher and Nagy, 1974].

The basic ideas behind JB2 are as follows:

The basic image is first segmented into individual marks (connected components of black pixels).
The marks are clustered hierarchically based on similarity using an appropriate distance measure.
Some marks are compressed and coded directly using a statistical model and arithmetic coding.
Other marks are compressed and coded indirectly based on previously coded marks, also using a statistical model and arithmetic coding. The previously coded mark used to help in coding a given mark may have been coded directly or indirectly.
The image is coded by specifying, for each mark, the identifying index of the mark and its position relative to that of the previous mark.

There are many ways to achieve the clustering and the conditional encoding of marks, the algorithm that we currently use is called "soft pattern matching" [Howard, 1997].

The key novelty with JB2 coding is the solution to the problem of substitution errors in which an imperfectly scanned symbol (due to noise, irregularities in scanning, etc.) is improperly matched and treated as a totally different symbol. Typical examples of this type occur frequently in OCR representations of scanned documents where symbols like 'o' are often represented as 'c' when a complete loop is not obtained in the scanned document, or a 't' is changed to an 'l' when the upper cross in the 't' is not detected properly. By coding the bitmap of each mark, rather than simply sending the matched class index, the JB2 method is robust to small errors in the matching of the marks to class tokens. Furthermore, in the case when a good match is not found for the current mark, that mark becomes a token for a new class. This new token is then coded using JBIG1 with a fixed template of previous pixels around the current mark. By doing a small amount of preprocessing, such as elimination of very small marks that represent noise introduced during the scanning process, and smoothing of marks before compression, the JB2 method can be made highly robust to small distortions of the scanning process used to create the bi-level input image.

Информацию об алгоритме JBIG2 можно почитать здесь:

http://ru.wikipedia.org/wiki/JBIG2

http://en.wikipedia.org/wiki/JBIG2

http://jbig2.com/

http://www.imperialviolet.org/binary/jbig2enc.html

http://www.jpeg.org/jbig/jbigpt2.html

http://jbig2dec.sourceforge.net/

Howard et al. The emerging JBIG2 standard (DjVu ENG, 420 КБ)

Сходства и различия между JB2 и JBIG2

Вот что мне рассказал об этом вопросе Leon Bottou, один из создателей формата DjVu (мои примечания даны курсивом):

JB2 был предложен фирмой AT&T в ответ на появление стандарта JBIG2. DjVu использует JB2, т.к. DjVu был создан задолго до того, как JBIG2 был готов или хотя бы даже работоспособен. Не было даже черновика (Draft) спецификации JBIG2 - поэтому JB2 пришлось делать практически "с нуля" (видимо, JBIG2 на тот момент существовал в виде лишь некоего набора общих идей).

JB2 был описан впервые в этом документе: http://citeseer.ist.psu.edu/howard97text.html. Этот документ был написан в 1996 году и опубликован в 1997 году. Именно с этого документа рекомендуется начинать изучение формата JB2 (JB2 сам по себе датируется примерно 1995 годом).

JB2 создал Paul G. Howard. Как с ним связаться в настоящее время - неизвестно.

У меня есть собственная копия спецификаций формата DjVu и она находится здесь: http://djvu.cvs.sourceforge.net/djvu/djvulibre-3.5/doc/. JB2 там описан в файле djvu2spec.djvu. Некоторые изменения для многостраничного кодирования описаны в файле djvu3spec.djvu.

JBIG2 значительно сложнее: его спецификация занимает почти 200 страниц, в то время как спецификация JB2 умещается на 19 страницах вместе с описанием арифметического кодёра. Это из-за того, что каждый член комитета по стандартам хотел добавить что-либо "своё" патентованное в JBIG2.

Вот результаты некоторых тестов - см. стр. 20 в http://leon.bottou.org/slides/djvu/index.djvu (для просмотра этого файла требуется броузерный DjVu-плагин, т.к. он в Indirect-режиме. У кого WinDjView - скачайте (если интересно) его Bundled-копию (379 КБ) - хотя тут чуть ниже приведён отдельно рисунок с той страницы).

Эти тесты были сделаны в 2001 году. JBIG2-кодировщики могли улучшиться с тех пор - но они улучшаются медленно, потому что стандарт JBIG2 слишком сложен и он сам по себе по-глупому теряет биты. JB2 не делает Halftoning - он этого просто избегает (т.е. не составляет словарь обобщённых Dithering-фрагментов, как это делает JBIG2). Всё остальное там работает вполне хорошо, в чём можно убедиться, посмотрев результаты теста.

JBIG2 появился после JB2, и его создатели могли публично привести его сравнение с JB2 - как Вы думаете, почему они это не сделали?

Охватывают ли словари разделённых символов в JBIG2 не только одну страницу, но и группу страниц, как JB2? Точно не знаю, но думаю, что вполне может быть. Но, повторюсь: JBIG2 настолько сложен, что мало какие JBIG2-кодировщики из уже реализованных используют все его возможности - "зарытые" в его спецификации.

Что лучше, JB2 или JBIG2? Я думаю, что JBIG2 - это обрюзгший неэффективный монстр, а JB2 - это компактная и эффективная система. Всё маленькое красиво. :)

А вот что мне рассказал на эту тему Patrick Haffner (также один из создателей формата DjVu):

Я не работаю с DjVu с 2000-года. На тот момент мы вынуждены были выпустить JB2, потому что JBIG2 не был ещё стандартизован, и по этой же причине мы не могли полноценно сравнивать эти 2 формата.

Основное различие в том, что JB2 использует ZP-кодёр, в то время как JBIG2 использует MQ-кодёр. На тот момент мы избрали путь разработки ZP-кодёра, потому что ситуация вокруг лицензирования MQ-кодёра была неопределена. Я не знаю, определена ли она сейчас?

Вот ещё одно сообщение от Leon Bottou, которое я считаю целесообразным привести без перевода:

Ok. Let me outline the main differences.

- JB2 and JBIG2 encode the datastream with two different arithmeric coders. The JB2 Z-Coder offers slighlty better compression ratios (negligible) and slighly better speed in the current implementation. The JBIG2 MQ-Coder would be a little cheaper to implement in hardware but that does not matter nowadays.

- A JB2 file is a sequence of records. Each record is like an instruction that can create a new mark, draw it on the screen and/or add it to the library of marks. Marks can be created from scratch or by cross-coding relative to a mark already stored in library. That gives the encoder a lot of flexibility. For instance, instead of inserting all marks into the library, you can insert only those that are used more than once. When you do so, you save on the bits used to identify marks but you loose a little bit on the bits used to describe the operations to perform. But you can also use this to make sure that halftone patterns do not go into the library of shapes. This is why JB2 does not need a special halftone mode.

- JBIG2 tries to save on the operation codes by defining a very structured file. First you have the general information, then all the library of marks ordered by groups of fixed height, then all the drawing information. Everything can be coded using Huffman codes (to try to reuse CCITT G4 hardware) or using the arithmetic coder. Plus a lot of special options to perform special halftoning modes, etc. Basically this is the union of the proposals of many members of the committee (mainly IBM and Xerox.)

This structured approach in fact saves nothing. For instance each JBIG2 drawing instruction must select a mark among all the marks in the file (which requires many bits) whereas the JB2 drawing must only select a mark among the marks already stored in the library by previous instructions (half the bits on average).

- A cool way to understand these differences is the "bits back" analysis. The basic idea is to assume that the arithmetic coder gets the best code size given its input (in practice the Z-Coder gets within 3% of that.) Now suppose the JBIG2 file contains 40 marks of the same height. Since any permutation of these marks can be used, there are factorial(40) ways to encode the same file while providing similar inputs to the arithmetic coder. Which way we choose can be understood as a hidden message of log2(factorial(40)) bits hidden at no cost into the JBIG2 stream. These are lost bits and there are many of them in JBIG2.

There are also many ways to encode a JB2 file since you can use different mixes of instructions. But to do so you must feed very different data to the arithmetic coder: different number of bits will be used to encode positions, identify marks, etc.. Therefore hiding bits into a JB2 file does not create a file of equivalent sizes. In simple cases you can compute how much you would loose relative to the best encoding option. When you do so, it becomes clear that JB2 looses much less bits than JBIG2.

JBIG2 does not do that right for several reasons. First they did not understand these fine details. Second they could not use the tricks we are using because they were adamant on making a variant of JBIG2 that did not use arithmetic coding. In JBIG2 you can choose speed by using G4 encoding or compression performance by using the MQ arithmetic coder. But this MQ mode was compromised by stupid choices favoring the G4 mode.

- JB2 is orders of magnitude easier to implement than JBIG2 because it is much simpler. This is why the DJVU viewers decode things rather quickly and use less memory (in fact most DJVU viewers decode on the fly while you scroll!) There is nothing PDF/JBIG2 can do except waiting for faster processors. So with JB2 you get speed and efficiency at the same time.

- Technically there is no doubt JB2 is superior because this is a pure design without the compromises of the JBIG2 committee, and with a finer understanding of the consequences of adaptive arithmetic coding. In my opinion, the DJVU viewers are much nicer to use, even though faster processors erase this advantage (on PCs but not on cellphones!)

- Yet it is true that the best technology does not always win. The DJVU businessmen made erroneous decisions more than once.

- L.

Посмотрите на диаграмму от Leon Bottou, сравнивающую скорость и уровень сжатия JB2 и JBIG2 (Это отдельно приведённая страница 20 из Indirect-файла http://leon.bottou.org/slides/djvu/index.djvu):

pdf01.gif (27134 bytes)

Примечания:

а. DjVuBitonal - это другое название JB2.

б. Цифры в круглых скобках непосредственно над синими и красными столбцами - это степень сжатия (Compression ratio).

в. "CCIT F4", "CCIT F7" и "CCIT F10" - это условные названия стандартизованных CCIT-ом тестовых картинок (для сравнения сжатия разных кодировщиков). Кому интересно, можете их скачать (3 ЧБ картинки в DjVu, 85 КБ).

По результатам этих тестов:

г. Lossy JB2 значительно меньше, чем арифметически закодированный lossy JBIG2 на большинстве текстовых изображений, и примерно одинаков с ним на простых и растрированных ("Halftone"; "Dithering") чёрно-белых изображениях.

д. Кодирование/декодирование у JB2 быстрее, чем у JBIG2.

е. Lossless JB2 в 1,4 раза меньше, чем JBIG1. [Inglis, 1999]

Сходства:

1. Наличие как lossy, так и lossless-режимов сжатия.

2. Использование посимвольной сегментации и словаря разделённых символов.

3. Оба формата хранят свою информацию в файле в виде "логических блоков" - у JB2 это chunks, у JBIG2 - segments.

Различия:

1. JB2 использует алгоритм "soft pattern matching", а JBIG2 - просто "pattern matching". JB2 заносит в словарь не только сами "разделённые" символы, но также разницу между ними и похожими символами (при lossless), а JBIG2 (вроде бы, точно не известно) так не умеет и заносит в словарь просто сами "разделённые" символы. JBIG2 значительно более символьно-искажающий, нежели чем JB2.

2. JB2 перед кодированием делает сглаживание символов - что даёт выигрыш размера до 10%. И делает Denoise - для aggressive-режимов. JBIG2 (вроде бы, точно не известно) ничего этого не делает.

3. JB2 использует словарь разделённых символов, охватывающий группу смежных страниц - а JBIG2 (вроде бы, точно не известно) составляет этот словарь в пределах одной страницы.

4. JBIG2 имеет свойство "Halftoning" - т.е. кодирование полутоновых изображений путём запоминания интенсивности изображения, а не позиции каждого их пикселя. Соответственно, JBIG2 делает не только посимвольную сегментацию (как и JB2), но также и сегментацию изображений. JB2 ничего этого не делает. Таким образом, JB2 не оптимизирован для хранения полутоновых изображений.

5. JB2 использует ZP-кодёр, а JBIG2 - MQ-кодёр.

(Однако, этот его недостаток полностью компенсируется в DjVu-файле за счёт того, что полутоновое изображение там может "размываться" пользователем, после чего он будет закодировано в DjVu-файле уже не при помощи JB2 - а посредством IW44 - что многократно более эффективно по размеру, нежели чем использование JBIG2).

Выводы:

В большинстве случаев, по критерию "эффективность сжатия" формат JB2 проявляет себя лучше, чем JBIG2. Исключение теоретически могут составлять изображения, содержащие полутоновые рисунки.

(Тесты сжатия описаны также в статье Compression of bi-level images)

Недостатки конвертера Pdftodjvu

1. Pdf-файлы, созданные в ABBYY FineReader с применением опции "Заменять неуверенно распознанные слова их изображениями", некорректно конвертируются в формат DjVu: картинки с изображением текста "съезжают" в сторону относительно букв текста - и в результате DjVu-файл становится плохо читабельным:

Исходный Pdf-файл, созданный в ABBYY FineReader 7 Pro с опцией "Заменять неуверенно распознанные слова их изображениями"

Соответствующий DjVu-файл, полученный из исходного Pdf-файла путём прямой конвертации в Pdftodjvu.

Желающие могут самостоятельно посмотреть этот Pdf-файл (312 КБ).

2. GhostScript, используемый в Pdftodjvu, "понимает" далеко не все Pdf-файлы - иногда он "вылетает" с ошибкой при конвертации какого-нибудь Pdf-файла. Вот пример такого Pdf-файла:

Скачать пример (215 КБ)

При этом GhostScript выдаёт примерно такое сообщение об ошибке:

AFPL Ghostscript 8.14 (2004-02-20)
Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 2.
Page 1
Page 2208x2775 ( fg-bw bg-empty )
Page 2
Error: /undefined in --token--
Operand stack:
2 1 --nostringval-- --nostringval-- --nostringval-- 245745 6 0 --nostringval-- Contents --nostringval-- Type Page Parent --nostringval-- Rotate 0 MediaBox --nostringval-- CropBox --nostringval-- Resources --nostringval-- ColorSpace --nostringval-- 9 --dict:9/9(ro)(G)-- --nostringval--
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- 3 1 2 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- %loop_continue --nostringval-- 2 1 1 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval--
Dictionary stack:
--dict:1128/1686(ro)(G)-- --dict:0/20(G)-- --dict:77/200(L)-- --dict:77/200(L)-- --dict:104/127(ro)(G)-- --dict:238/347(ro)(G)-- --dict:18/24(L)--
Current allocation mode is local
AFPL Ghostscript 8.14: Unrecoverable error, exit code 1
PDF to DjVu(tm) Command Line Encoder 5.0.0 Build 973
Copyright (c) Lizardtech and AT&T. All rights reserved.
Open event "PDFtoDjVu_GUI_3233c2093" for waiting for cancelation.
pdftodjvu: Execution of gs failed

У этой проблемы есть такое решение: открыть проблемный Pdf-файл в Adobe Acrobat (в полной версии, не-Reader), сохранить его в формат Ps, и конвертировать уже этот Ps-файл в Pdftodjvu вместо исходного Pdf-файла.

При этом возможны некоторые "косметические" изменения вида содержимого файла - например, могут самопроизвольно увеличиться поля в DjVu-файле (по сравнению с исходным Pdf-файлом).

3. При конвертации русскоязычных векторных Pdf-файлов в результирующем DjVu-файле нередко создаётся такой OCR-слой, где вместо русскоязычного текста оказываются какие-то дикие крякозяблы. Вот как они выглядят в текстовом редакторе:

См. образец "плохого" Pdf-файла (69 КБ)

В то же время, бывает и так, что конвертация проходит вполне успешно - и в созданном OCR-слое конечного DjVu-файла оказывается нормальный русский текст:

См. образец "хорошего" Pdf-файла (90 КБ)

Я опробовал переконвертировать в DjVu несколько русскоязычных векторных Pdf-файлов посредством Pdftodjvu - и заметил такую закономерность:

1. Если при конвертировании Pdftodjvu выдаёт примерно такое сообщение об ошибке:

- то в этом случае получается DjVu-файл, где в OCR-слое оказываются крякозяблы.

2. Если при конвертировании Pdftodjvu вообще ни на что не "ругается", то всё нормально - получается DjVu-файл, где в OCR-слое оказывается нормальный русский язык.

У меня такое предположение: нормально конвертируются в DjVu только те векторные русскоязычные Pdf-файлы, где фонты находятся в состоянии "embedded". А если фонты не "embedded" - тогда получаются крякозяблы (в OCR-слое DjVu-файла).

Наиболее простое решение "проблемы с крякозяблами" - распознать при помощи FineReader полученный DjVu-файл и внедрить в него новый "нормальный" OCR-слой.

Можно попробовать перевести фонты в Pdf-файле в состояние "embedded". Но это не всегда возможно и требует более высокой квалификации пользователя.

Напоследок я предлагаю почитать, что пишут о формате Pdf опытные книгосканировщики.

Книгосканировщики о формате Pdf

Автор: Astra55, Отправлено:14:24 28-08-2005

Одной из самых трудных задач при работе с файлами Pdf является их WYSIWIG-редактирование, особенно текста. Нередко бывает нужно перевести статью с английского (или другого языка) на русский или проделать обратную операцию. Если бы статья состояла из одного только текста, то тут вопросов нет, банальное Copy/Paste и вперёд. Иногда бывают трудности с отображением того или иного шрифта, но это всё преодолимо подручными средствами. Да и конвертеров из PDF в текст (plain, doc, rtf, html) хватает. Для примера - Glenn Alcott PDF Converter, Midas Extractor, китайская троица - Easy PDF to HTML Converter, Easy PDF to Word, Easy PDF to Text (сохраняет постранично, зато freeware) от http://www.pdf-to-html-word.com и еще PDF2HTML от другого китайца VeryPDF, PDF2Text от Traction. Указаны только те конвертеры, которые могут более-менее корректно работать с русским языком и сохранять хотя бы подобие исходного форматирования. Причём это зависит от исходного текста, точнее, от применённых в нём фонтов. Бывает, что некоторые из упомянутых софтов на одних текстах работают отлично, а на других выдают полную лажу, и наоборот.

Можно попробовать обойтись одним софтом типа Solid PDF Converter 2, PDF Grabber 2 или ScanSoft PDF Converter 3, который, кстати, тоже может редактировать текст, хотя с такими трудностями и тормозами, что лучше этого не делать. Последние софты сами по себе немаленькие, ScanSoft весит 73 мега. Если в тексте есть картинки, то размеры выходного файла, doc или rtf, достигают десятков и даже сотен мегабайт, Ворд открывает такие файлы по несколько минут, а бывает вообще виснет. Но дело вкуса, если монстры устраивают, то пользуйтесь ими. Только что попробовал SolidPDF для извлечения plain-текста на двух книгах. На обеих он вчистую проиграл более простым конвертерам - Glenn и PDF to text. Книгу о Гарри Поттере конвертят только Glenn (вместо шпации лепит два обычных тире, но это пустяк) и PDF Grabber, последний несколько кривовато в плане переносов, зато "Как выжить в тюрьме" тот же Glenn выдает в виде точек и пробелов, что подтверждает сказанное ранее.

Поэтому наибольший интерес вызывают средства редактирования самого Pdf-файла, без преобразования в какой-нибудь промежуточный формат. Рассмотрим известные мне софты для этой цели, их не так много - FoxIt PDF Editor, CAD-KAS PDF Editor, eXPert PDF Editor, VeryPDF PDF Editor. Если их работу с графикой ещё можно терпеть, то как текстовые редакторы они практически бесполезны, равно как и Акробаты всех версий. Все упомянутые софты воспринимают текст в виде строк или даже отдельных букв. Попытка перевести хотя бы абзац с английского языка на русский быстро приведет к бешенству, ибо весьма напоминает особо изощренный мазохизм :).

К этим "достоинствам" добавляется еще одно и очень неприятное - дикие напряги с русскими фонтами. Некоторые софты ещё соглашаются внедрить русский фонт, например CAD-KAS-овский редактор, но без ухищрений с самим фонтом что-либо делать всё равно нельзя. Это преодолимо только при использовании редактора фонтов FontLab или аналогичного. Другие вообще категорически отказываются иметь дело с кириллицей, как тот же FoxIt. Китайский редактор от VeryPDF может считаться WYSIWIG только условно в отличие от остальных. Он ухитряется "на лету" конвертить Pdf во что-то другое, сильно похожее на html, и страницы только отдалённо напоминают оригинал. Акробаты всё знают, но от этого не легче, их можно использовать для чего угодно, но только не для редактирования текста. Если знаете ещё редакторы для Pdf, то поделитесь с публикой, мои познания в этом плане кончились.

Резюме - нет в жизни счастья, нет WYSIWYG редактора для Pdf.

Всё оно было бы так, но вот в руки попался английский софт Infix PDF Editor от Iceni Technology. Сразу скажу - опять-таки идеал недостижим и не всё в нём сделано по уму, но одна фича сразу окупает все недостатки. В нём можно работать с Pdf-текстом, как в обычном текстовом редакторе, ну или близко к этому, причём показывает непечатаемые знаки сразу, что очень удобно. Только за корректную работу с фонтами, абзацами и даже страницами, можно возлюбить Infix пылкою любовию :). Если на странице только один фонт и нет картинок, то достаточно просто выделить текст и сменить фонт на кириллический. Само собой, что не все фонты будут правильно отображаться, но это уже детали, не имеющие значения, поскольку при помощи FontLab можно сделать в этом плане что угодно. Во всяком случае основные фонты - Arial, Lucida, TNR, MSS - работают нормально. Не удивляйтесь только увеличению объёма файла, сначала загляните в виндовую папку Fonts и полюбопытствуйте на размер файла выбранного фонта. Бесплатных пирожных не бывает, хотя можно кое-что сделать при помощи того же FontLab-а, типа удаления ненужных символов после кириллицы. Выбранный фонт эмбеддится на автомате, без каких-либо телодвижений со стороны юзера. Второе огромное достоинство Infix редактора - Undo без ограничений и даже мгновенный возврат к последнему сохраненному состоянию в меню "File", там есть "Revert to saved". Недостатки большей частью эргономические, можно было сделать интерфейс куда удобнее, задавать замену фонтов заранее и т.д. Но всегда хочется больше, чем предлагают, такая у юзера натура :). Может и доработают Infix до немыслимого совершенства, хотя шансов не так много. Интересно, что в ресурсах экзешника Infix сидит масса окон, не имеющих к Infix никакого отношения. То ли схалтурили девелоперы, то ли будут их использовать при будущих доработках. Для восточных языков можно скачать дополнительный пакет, но мне это было не нужно.

Второе резюме - если нужно редактировать Pdf-файлы, то Infix можно отнести к категории Must Have.

Испытания софта проводились под ShadowUser - мегарулезная штука (Must Have 4eva!), кто знает, кто не знает - качать, ставить и юзать. Ставил сразу по двадцать разных программ, после перезагрузки всё чисто, можно начинать сначала :).

Автор: Astra55, Отправлено:21:57 26-05-2006

Господа, давайте не упоминать всуе формат Pdf. По большому счету, он имеет отношение к сканированию книг исключительно в плане перегонки Pdf в DjVu и конвертации из Ворда и прочих редакторов в Pdf. На этом список закончен. Сканирование и Pdf - две вещи несовместные, как бы и что бы ни делали, ибо растр не может быть просто так преобразован в вектор. Сканер же по сути может выдать только растр.

На эту тему уже много раз говорили, спорили и вроде пришли к консенсусу :).

В FAQ, что ли, эти постулаты записать, иначе всё равно будут сканировать в Pdf...

Автор: are, Отправлено:23:02 26-05-2006

Единственная причина, по которой я вижу необходимость переводить DjVu->Pdf - это совместимость с юзерами, которые не знают, что такое DjVu (таких подавляющее большинство). Предположим, я хочу послать некую книгу некоему пожилому человеку в далёкой стране. (Он еле-еле освоил мышку и знает, что на ней кнопки надо нажимать почему-то дважды и быстро подряд - почему-то один раз не работает. Кто это так неудобно придумал? Ну да ладно. Человек мучается, но нажимает быстро дважды. С четвёртого раза получается.) Так вот, такому человеку будет невозможно объяснить, что надо поставить какой-то ещё софт. Ну и вообще - большинство народа в сети вообще не слышало о DjVu , JBIG2, Vector, Bitmap, и не понимают разницы между OCR и MS Word. ("Помогите конвертировать MP3 в MS Word - конвертер для формата Интернета уже есть"). Но все знают, что такое Pdf - это "такие файлы как книга на экране".

Поэтому полезно иметь возможность перевести DjVu->Pdf хоть как-нибудь (с потерей OCR, линков и т.д.), лишь бы на экране было видно и печаталось. При обычном переводе DjVu -> TIFF G4 -> Pdf размер подскакивает в 3-4 раза. А если переводить в Pdf JBIG2, то размер будет небольшой.

Автор: are, Отправлено:17:21 30-07-2006

Оптимальная растеризация Pdf - очень сильно зависит от содержимого Pdf (вектор, растр, или комбинация вектора и растра? цвет? истинное разрешение растров внутри Pdf? это для всех страниц одинаково, или нет? в каком разрешении запускать GS, чтобы не перемасштабировать растры? делать ли antialias?)

Из-за этого в "конвейере" all2djvu предусмотрено много разных способов растеризации Pdf:

1) pdfimages (самый надёжный способ не испортить растры излишним масштабированием, но иногда даёт слишком сложные результаты).
2) pdftoppm (самый надёжный способ получить визуально приемлемый результат, если угадать правильное разрешение).
3) gs (самый быстрый, но не всегда работает).
4) acroread -> ps -> pdf -> pdftoppm (применяется только в случае, если уже ничто другое не помогает, для особо кривых Pdf-файлов).
5) gs или pdftoppm + automatic color downgrade, no antialias (это если растры по содержанию чёрно-белые, а формально серые или цветные).
6) gs или pdftoppm + upsample -> color or black/white (это если растры серые или цветные, в низком разрешении).
7) pdftodjvu.exe (только для Pdf с векторным текстом, результат приходится всегда проверять вручную).

Автор: monday2000.

26 декабря 2007 г.

E-Mail (monday2000 [at] yandex.ru)