Короче говоря: форма в вашем PDF повреждена, она требует использования шрифта без надлежащего сопоставления между кодами символов и кодовыми точками Unicode.Кроме того, все глифы в этом шрифте пусты, поэтому, даже если процессор PDF каким-то образом получит идею для отображения, он все равно будет отображать только пустые символы.
Таким образом, процессор PDF должен игнорировать запросыи введите собственный шрифт, чтобы заполнить форму так, как вы ожидаете, чтобы она была заполнена.
Анализ внешнего вида поля формы не сплюснутый PDF
В вашем вопросе вы заявляете
Все работает нормально, пока я не звоню
form.FlattenFields();
после тех полей, которые заполнены текстом, разбиты
На самом деле, тем не менее, уже ваш unPDF-файл поврежден:
И это не из-за средства просмотра, поток появления этого поля формы выглядит следующим образом:
q
0 0 0 RG
0 0 151 12.36 re
S
Q
/Tx BMC
q
n
q
BT
/F0 12 Tf
4 1.32 Td
0.26667 0.26667 0.26667 rg
<0000000000000000> Tj
ET
Q
Q
EMC
Как видите, показана строка <0000000000000000>, то есть четыре 0000 глифа.Однако этот шрифт может быть закодирован, но он не может представлять "Text".
"Text" в этом PDF-файле только один раз: в качестве значения поля абстрактной формы.Таким образом, если средство просмотра PDF не принимает вид, заданный в PDF, но создает его сам (например, при редактировании поля формы), он может отображать что-то, представляющее "Text".
Анализ исходной формы
Увидев, что исходная заливка без выравнивания уже повреждена, и задаемся вопросом, что могло вызвать это, давайте посмотрим на свойства поля формы.
Прежде всего, это значение * 1039Атрибут * DA (внешний вид по умолчанию), который используется при построении приведенного выше потока внешнего вида:
.266667 .266667 .266667 rg
/F0 12 Tf
Вы узнаете обе инструкции (определение цвета в предыдущей строке, определение шрифта и размера шрифта)во втором) в приведенном выше потоке внешнего вида.
Имя шрифта F0 как в ресурсах внешнего вида, так и в ресурсах по умолчанию ( AcroForm запись DR) разрешается к тому же шрифту:
28 0 obj
<<
/Type/Font
/BaseFont/WRCKAA+TimesNewRomanPSMT
/ToUnicode 29 0 R
/Subtype/Type0
/DescendantFonts[33 0 R]
/Encoding/Identity-H
>>
endobj
Кодировка Identity-H , что по сути означает, что символ coВ PDF используются те же коды, что и в шрифте.Таким образом, нет никакой информации о действительном значении кода.
Но есть карта ToUnicode , упомянутая выше!Давайте посмотрим на его содержание:
/CIDInit /ProcSet findresource
begin
12 dict
begin
begincmap
/CIDSystemInfo <</Ordering (UCS) /Registry (Adobe) /Supplement 0 >> def
/CMapName /Adobe-Identity-UCS def
/CMapType 2 def
1 begincodespacerange
<0000> <ffff> endcodespacerange
1 beginbfchar
<0003> <0020> endbfchar
endcmap
CMapName
currentdict
/CMap defineresource
pop
end
end
Только одно сопоставление, код символа 0003 сопоставлен с 0020, кодовая точка Unicode для пробел , больше ничего!
Таким образом, определение формы просит процессор PDF использовать определенный шрифт для заполнения, но этот шрифт не предоставляет информации о том, какие коды символов в этом шрифте представляют какое значение Unicode. Таким образом, процессор PDFпопытка сделать так, как было запрошено, может привести к сбою только при заполнении формы!
Кроме того, шрифт имеет значение BaseFont WRCKAA + TimesNewRomanPSMT .Этот 6-буквенный префикс указывает, что этот шрифт не является полным TimesNewRomanPSMT, а только его подмножеством.Итак, давайте посмотрим на информацию об отрисовке глифа в шрифте:
и т. д. и т. д. для более чем 4000 глифов.
Таким образом, шрифт имеет только непустой рисунок для первого глифа (который называется ".notdef", т. Е. Он предназначен для обозначения неопределенных глифов), все остальные глифы нарисованы пустыми!
Более тогошрифт содержит собственную информацию о сопоставлении кода символа с Юникодом (в противном случае в таблице не было бы заголовков символов).Обработчику PDF не требуется использовать эту информацию, но если бы он использовал ее, он был бы одурачен использованием кодов символов, которые в конечном итоге все представляют только пустые глифы!