създаване на pdf чрез конвертиране на .doc, конвертиране на ps

Първо: не е правилно да се твърди, че „.doc файл се преобразува в PDF“. Това не е никакво преобразуване; по-скоро документът се изобразява на виртуален принтер и виртуалният принтер записва PDF текстови команди, които формират страниците. Редът, в който обектите (текст и графики) се появяват в PDF, не се определя от съдържанието на оригиналния документ; виртуалният принтер може да обработва обектите във всеки ред.

Не бъркайте TJ и Tj. Според PDF справка 1.7 на Adobe :

5.3.2 Оператори за показване на текст ...

низ 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“ е очевидна; но защо "1Въведение"? Това грешка при декодирането ли беше? По-нататъшна проверка показа, че „1“ е зададено на размер 1,98 pt и с цвят на запълване „Бяло“ (всъщност се появи, когато поставих черен правоъгълник зад цялата страница). Предполагам, че това беше само един от триковете на наборчика: като включи номера на главата на същия ред, той можеше да накара своя софтуер (Framemaker) автоматично да генерира правилния текст „Bookmark“ от този ред, включително „1“. Разбира се, "1" не трябва да се вижда на самата страница, затова той го постави малък и бял.