создание pdf путем преобразования .doc , преобразования ps

Как обрабатывается текст при преобразовании файла .doc в файл .pdf. Я пытался перехватить оператор "Tj" с помощью Pdfbox. Предложение "взаимозаменяемые функции PDF. Опять же, результирующий файл PDF можно просмотреть с помощью приложения для просмотра, такого как ", разбитого на

"функции обмена PDF. Agai" & "n, полученный файл PDF можно просмотреть с помощью приложения для просмотра, например ". Аргументы оператора TJ были

[COSArray{[COSString{in}, COSInt{5}, COSString{t}, COSInt{5}, COSString{er}, COSInt{-4}, COSString{ch}, COSInt{5}, COSString{an}, COSInt{4}, COSString{g}, COSInt{5}, COSString{e }, COSInt{-2}, COSString{f}, COSInt{10}, COSString{eat}, COSInt{5}, COSString{ur}, COSInt{10}, COSString{es o}, COSInt{6}, COSString{f }, COSInt{-2}, COSString{P}, COSInt{6}, COSString{DF}, COSInt{6}, COSString{.}, COSInt{13}, COSString{ Ag}, COSInt{3}, COSString{ai}]}] and 

[COSArray{[COSString{n, t}, COSInt{6}, COSString{he }, COSInt{10}, COSString{r}, COSInt{-2}, COSString{esu}, COSInt{5}, COSString{lt}, COSInt{8}, COSString{in}, COSInt{5}, COSString{g}, COSInt{5}, COSString{ P}, COSInt{4}, COSString{DF}, COSInt{6}, COSString{ f}, COSInt{-2}, COSString{il}, COSInt{5}, COSString{e }, COSInt{8}, COSString{ca}, COSInt{4}, COSString{n b}, COSInt{3}, COSString{e }, COSInt{8}, COSString{view}, COSInt{9}, COSString{ed wit}, COSInt{6}, COSString{h a}, COSInt{14}, COSString{ v}, COSInt{-3}, COSString{ie}, COSInt{12}, COSString{we}, COSInt{8}, COSString{r}, COSInt{8}, COSString{ app}, COSInt{5}, COSString{li}, COSInt{5}, COSString{ca}, COSInt{4}, COSString{t}, COSInt{5}, COSString{io}, COSInt{7}, COSString{n, s}, COSInt{6}, COSString{uc}, COSInt{5}, COSString{h as}, COSInt{7}, COSString{ }]}]

Это из-за того, как .doc конвертируется в pdf? или это из-за текстовых блоков, упомянутых в последнем ответе на этот вопрос . Каково значение этих COSInt между COSString ? я действительно не понимаю о текстовом блоке, но я не думаю, что должна быть проблема, если я попытаюсь перехватить оператор Tj. Будет ли это то же самое, если я попытаюсь обработать PDF-файл, созданный из PDF-файла?


person programer8    schedule 25.12.2013    source источник


Ответы (1)


Прежде всего: неправильно утверждать, что «файл .doc конвертируется в PDF». Это не обращение любого рода; скорее, документ отображается на виртуальном принтере, и виртуальный принтер записывает текстовые команды PDF, формирующие страницы. Порядок, в котором объекты (текст и графика) появляются внутри PDF-файла, не определяется содержимым исходного документа; виртуальный принтер может обрабатывать объекты в любом порядке.

Не путайте TJ и Tj. Согласно справочнику по Adobe PDF 1.7 :

5.3.2 Операторы отображения текста...

string Tj Показать текстовую строку.

массив TJ Отображение одной или нескольких текстовых строк с возможностью индивидуального позиционирования глифов. [...] Число выражается в тысячных долях единицы текстового пространства.

Tj показывает непрерывную текстовую строку, для TJ COSInts между ними представляют собой горизонтальные смещения между отдельными текстовыми строками. Однако это не означает, что все, нарисованное с помощью Tj, изначально было одной текстовой строкой. Генератор PDF может разбить одно более длинное предложение на отдельные Tj инструкций; например, для группировки текстов одинакового шрифта и размера вместе.

Точно так же массив TJ может содержать только очень небольшие корректировки между отдельными текстовыми фрагментами для реализации кернинга или отслеживания на уровне символов; но он также может содержать большие расстояния для создания настраиваемых пробелов, имитирующих табуляции или символов надпечатки.

"Текстовый блок", на который вы ссылаетесь, представляет собой строковые операнды:

Строковый операнд оператора отображения текста интерпретируется как последовательность кодов символов, идентифицирующих глифы, которые нужно нарисовать.

..

Строки, представляемые операторам вывода текста, могут быть любой длины — даже с кодом одного символа на строку — и могут располагаться на странице в любом порядке. Группировка глифов в строки не имеет значения для отображения текста. Отображение нескольких глифов с одним вызовом оператора отображения текста, такого как Tj, приводит к тем же результатам, что и их отображение с отдельным вызовом для каждого глифа.

Возможная проблема заключается в расположении строк TJ/Tj. Обычно текст отображается в порядке чтения: слева направо, сверху вниз. Но такие элементы, как верхние и нижние колонтитулы, рисунки или таблицы, всегда могут отображаться первыми или последними. Кроме того, если фрагменты текста отображаются по шрифту/размеру, вы можете найти (например) сначала весь текст, набранный прямым шрифтом, затем весь текст, выделенный курсивом, и, наконец, весь текст, набранный жирным шрифтом.

В большинстве случаев невозможно точно извлечь исходный текст из PDF-файла. И TJ, и Tj [a] форматируют только горизонтальные фрагменты текста (на самом деле они также могут отображать вертикальный текст), и исходное соотношение между текстовыми фрагментами не сохраняется, поскольку виртуальный принтер никогда не знал об этом с самого начала.

[a] Есть еще две команды рендеринга текста: ' и " делают то же самое, что и TJ и Tj, но дополнительно позиционируют «текущую точку» как «начало следующей строки» и это, в свою очередь, нуждается в интерпретации значения «ведущий» и «начало текущей строки».

Еще одно предостережение заключается в том, что кодировка символов в текстовых операндах может быть не такой, как вы ожидали. PDF-принтер может свободно переупорядочивать или изменять кодировку символов, например, когда шрифт был подмножеством, или для доступа к специальным символам за пределами кодировки шрифта по умолчанию. Таким образом, вы можете вернуть строку как

[ (\251 1985\205) 6.4 (2006 A) 24 (d) 1 (o) 9.7 (b) -12.3 (e) ] TJ

(первая строка страницы 2 справочника PDF 1.7). Восьмеричные символы \251 (169 в десятичном формате) и \205 (133 в десятичном формате) — это символы © и ; первый также является обычным кодом ISO-Latin1, а второй — нет — этот текст находится в PDFEncoding (Приложение D, Наборы символов и кодировка). Кодировка может отличаться от шрифта к шрифту в вашем документе (а также возможно, что у вас есть дубликаты шрифта с разными кодировками). Кодировка также может быть полностью пользовательской (с использованием \000 для «A», \001 для «d» и т. д.) или храниться как разница с одной из стандартных кодировок:

7 0 obj @ 319814        % Encoding
<<
  /Type         /Encoding
  /Differences  [ 32 /space 38 /ampersand 44 /comma /hyphen /period /slash /zero /one /two /three 53 /five /six /seven /eight /nine /colon /semicolon 65 /A /B /C /D
      /E /F /G /H /I 75 /K /L /M /N /O /P 82 /R /S /T /U /V /W /X 90 /Z 95 /underscore 97 /a
      /b /c /d /e /f /g /h /i /j /k /l /m /n /o /p /q /r /s /t /u /v /w /x /y /z 133
      /endash 141 /quotedblleft /quotedblright 169 /copyright ]
>>
endobj

Добавление

PDF Reference 1.7 сам по себе является интересной целью. Изучая текст на стартовой странице главы, стр. 25 («Глава 1 — Введение»), я обнаружил это:

25
CHAPTER 1
1Introduction
The Adobe Portable Document Format (PDF) is the native file format of the ..

«25» — это номер страницы внизу, а «ГЛАВА 1» очевидна; но почему "1Introduction"? Это была ошибка декодирования? Дальнейшая проверка показала, что «1» имеет размер 1,98 pt и цвет заливки «Белый» (на самом деле это проявилось, когда я поместил черный прямоугольник позади всей страницы). Я предполагаю, что это был всего лишь один из приемов наборщика: включив номер главы в ту же строку, он мог заставить свое программное обеспечение (Framemaker) автоматически генерировать правильный текст «Закладка» из этой строки, включая «1». Конечно, цифра «1» не должна быть видна на самой странице, поэтому он сделал ее маленькой и белой.

person Jongware    schedule 26.12.2013