Прямоугольники вместо букв после выравнивания поля в форме pdf с использованием iText

#c# #pdf #itext

#c# #PDF #itext

Вопрос:

Я заполняю форму PDF с использованием iText на C #. Необходимо заполнить переключатели и текстовые поля, и когда я закончу, я хочу, чтобы эти поля были не редактируемыми — сглаженными. Все работает нормально, пока я не вызываю

 form.FlattenFields();
  

после этого поля, которые где-то заполнены текстом, разбиваются — каждая буква превращается в прямоугольник. Когда я не вызываю form.FlattenFields (), эти поля в порядке, но все еще доступны для редактирования, что не то, что я хочу. Код:

 PdfReader reader = new PdfReader(src);

PdfDocument pdf = new PdfDocument(reader, new PdfWriter(dest));

PdfAcroForm form = PdfAcroForm.GetAcroForm(pdf, true);

form.GetField("question1").SetValue("Text");

form.FlattenFields();

pdf.Close();
  

Комментарии:

1. Пожалуйста, добавьте свой документ, чтобы мы могли протестировать ваш код

2. Этот документ был создан так же, как и основной документ. Папка содержит 3 файла — пустую форму для заполнения, результат без выравнивания и результат с выравниванием uploadfile.pl/pokaz/1699135—gvm4.html

3. Уже в «no_flatten.pdf» я вижу только эти прямоугольники.

4. @J.Doe У вас все еще есть открытые вопросы в отношении вашего вопроса? Тогда, пожалуйста, поделитесь ими. Или мой ответ достаточно отвечает на это? Затем, пожалуйста, отметьте это как принятое, нажав на галочку в левом верхнем углу.

Ответ №1:

Короче говоря: форма в вашем PDF повреждена, она запрашивает использование шрифта без надлежащего сопоставления между кодами символов и кодовыми точками Unicode. Кроме того, все глифы в этом шрифте пусты, поэтому, даже если PDF-процессор каким-то образом получит представление о сопоставлении, он, тем не менее, отобразит только пустые глифы.

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

Анализ внешнего вида поля формы в формате PDF без выравнивания

В своем вопросе вы утверждаете

Все работает нормально, пока я не вызываю

 form.FlattenFields();
  

после этого поля, которые были заполнены текстом, разбиваются

На самом деле, однако, ваш не сглаженный PDF-файл уже поврежден:

снимок экрана

И это не из-за программы просмотра, поток отображения этого поля формы выглядит следующим образом:

 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" .

Анализ исходной формы

Увидев, что исходное заполнение без выравнивания уже нарушено, и задаваясь вопросом, что могло быть причиной этого, давайте посмотрим на свойства поля формы.

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

 .266667 .266667 .266667 rg
/F0 12 Tf
  

Вы узнаете обе инструкции (определение цвета заливки в первой строке, определение шрифта и размера шрифта во второй) в потоке оформления выше.

Имя шрифта F0 как в ресурсах потока внешнего вида, так и в ресурсах по умолчанию (AcroForm entry 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, что по сути означает, что коды символов, используемые в 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, а только его подмножеством. итак, давайте посмотрим на информацию о рисовании глифа в шрифте:

Символы F0

и так далее, и так далее для более чем 4000 символов.

Таким образом, шрифт имеет непустой рисунок только для первого глифа (который называется ".notdef" , т. Е. он предназначен для замены неопределенных символов), все остальные символы отображаются пустыми!

Кроме того, шрифт содержит собственную информацию о сопоставлении кода символа с Unicode (в противном случае в таблице не было бы заголовков символов). Процессору PDF не требуется использовать эту информацию, но если бы он их использовал, его бы обманули, заставив использовать коды символов, которые в конечном итоге представляют собой только пустые глифы!