Ошибка отображения шрифта PDF

При рендеринге PDF-файла, созданного PDFCreator 0.9.x. Я заметил, что он содержит ошибку в сопоставлении символов. Теперь ошибка в файле PDF не вызывает удивления, Acrobat творит чудеса при отображении неисправных файлов PDF, поэтому многие генераторы PDF создают PDF-файлы, которые не полностью соответствуют стандарту PDF.

Я пытаюсь создать небольшой файл примера: http://test.continuit.nl/temp/Document.pdf

На одной странице отображается один глиф (заглавная буква A) с помощью команды Tj (см. поток 5 0 obj). Выбранный шрифт (7 0 obj) содержит шрифт с одним встроенным глифом. Все идет нормально. На char ссылается char #1. Учитывая кодировку шрифта, он содержит часть различий: [ 1 /A ]. Таким образом, char 1 -> символ /A. Теперь во встроенном шрифте подмножества есть cmap, который не соответствует глифу в символе 65 (например, заглавной A). Раздел cmap шрифта определяет символ в точном порядке в файле PDF Font -> Encoding -> Differences массив.

Похоже, что сопоставление/кодирование символов выполняется дважды. Похоже, затронуты только файлы из PDFCreator 0.9.x.

Мой вопрос: правильно ли это (или я сделал ошибку и правильный ли PDF) и что бы вы сделали, чтобы обнаружить эту ситуацию, чтобы решить проблему рендеринга.

Примечание. Мне нужно иметь возможность отображать эти PDF-файлы.

Решение

В файле ISO32000 есть примечание, что символические шрифты TrueType (в дескрипторе шрифта установлен бит 3) кодировка не разрешена, и вы должны ИГНОРИРОВАТЬ ее, всегда используя простую кодировку 1 на 1. В общем, если это символический шрифт, я полностью игнорирую объект Encoding, и это решает проблему.


person Ritsaert Hornstra    schedule 21.08.2011    source источник
comment
Чем вы рендерите файл?   -  person userx    schedule 22.08.2011
comment
@userx: мой собственный модуль визуализации PDF, написанный на Delphi. Он преобразует PDF-файл из памяти в устройство GDI (обычно это растровое изображение, но это также может быть принтер или любой другой контекст устройства GDI).   -  person Ritsaert Hornstra    schedule 22.08.2011


Ответы (1)


Во-первых, файл открывается и правильно отображается в Acrobat, поэтому почти наверняка файл правильный. На самом деле он правильно открывается и отображается у широкого круга потребителей PDF, так что на самом деле это правильно.

Рассматриваемый шрифт является шрифтом TrueType, так что на самом деле да, есть два вида «кодирования». Во-первых, это кодирование PDF/PostScript. Это сопоставляет код символа с именем глифа. В вашем случае он сопоставляет код символа 1 с именем глифа /A.

В шрифте PostScript мы затем искали имя /A в словаре CharStrings, и это давало нам описание символа, которое мы затем выполняли. Однако со шрифтом TrueType все по-другому.

Вы можете найти это на странице 430 Справочного руководства 1.7 PDF, где говорится, что:

«Встроенная кодировка программы шрифтов TrueType напрямую отображает коды символов в описания глифов с помощью внутренней структуры данных, называемой «cmap» (не путать с CMap, описанным в разделе 5.6.4, «CMaps»).

Я считаю, что в вашем случае вам просто нужно использовать код символа (0x01) непосредственно в подтаблице CMAP. Это даст вам GID 36.

person KenS    schedule 22.08.2011
comment
Что касается вашего первого пункта: после создания средства визуализации PDF в течение года я могу сказать вам: Acrobat исключительно хорошо поддерживает рендеринг ошибочных PDF-файлов. В основном отсутствуют ключи в объектах PDF. Эти проблемы особенно заметны при обработке шрифтов. - person Ritsaert Hornstra; 22.08.2011
comment
Я вижу то же самое, за исключением последнего абзаца: в содержании есть коммандос для рисования char 0x01. учитывая кодировку шрифта, это Postscript char /A. Шрифт TT не имеет заполненного раздела POST, я использую cmap TT, как и любой другой PDF-файл со шрифтами TT (не typ0), и мне нужно искать символ 65, учитывая имена форм таблицы перевода Acrobat в коды Unicode. Большинство PDF-файлов работают правильно, только тот, который создан с помощью PDFCreator (насколько я вижу сейчас), не нуждается в этом. Обратите внимание, что и Mac, и MS cmap в шрифте TT используют одно и то же сопоставление. Другим действительно нужна кодировка в PDF. - person Ritsaert Hornstra; 22.08.2011
comment
Обратите внимание, что на странице 431 стандарта PDF 1.7 говорится, что вы должны сначала использовать Endoding Dictionary и Differences там, а затем. Если присутствует (3, 1) подтаблица «cmap» (Microsoft Unicode), сначала сопоставьте имя PS, затем в значение Unicode, а затем используйте подтаблицу (3,1). Это именно то, как работает рендерер и дает неправильный результат (в случае файлов PDFCreate или 0.9.x). - person Ritsaert Hornstra; 22.08.2011
comment
Отвечая на один комментарий, я сказал, что пробовал несколько других потребителей PDF, а также Acrobat, и они тоже могут правильно обрабатывать этот файл. Я не полагаюсь на Acrobat. FWIW Я работаю над рендерингом PDF-файлов с версии 1.0 спецификации, около 15 лет. - person KenS; 24.08.2011
comment
Не допускается иметь объект кодирования в шрифте de для символического шрифта (бит 3 установлен в дескрипторе de). Я пытался всегда использовать кодировку, но игнорирование ее в этом случае помогло. в файле ISO32000 это гораздо яснее, чем в документе PDF 1.7 от Adobe. Это не совсем то же самое, что и ваш ответ, но, поскольку он действительно правильный, я приму ваш ответ. - person Ritsaert Hornstra; 08.01.2012
comment
Спецификация PDF 1.7 рекомендует, чтобы у вас не было кодировки с символическим шрифтом TrueType, спецификация PDF/A говорит, что у вас не должно быть кодировки. У меня нет под рукой копии спецификации ISO, хотя я думал, что она не похожа на спецификацию 1.7, но, думаю, это не так. В любом случае, это не очень хорошая идея, так как это сбивает с толку некоторых потребителей. Я рад, что вы нашли решение. - person KenS; 09.01.2012
comment
Правильный. основная проблема заключалась в следующем: это то, что PDFCreator генерирует по умолчанию для всех встроенных шрифтов TT. Я начал сканировать весь документ ISO, и тут и там стало намного яснее, как обращаться с такими случаями. - person Ritsaert Hornstra; 10.01.2012