Form field looses font type after flatten

[thomasbaustert]

We are using hexapdf to fill out PDF template. The form contains text fields with font Times New Roman.

When using iText the generated PDF contains the inserted text in Times New Roman. See itext.pdf

When using hexapdf with form fields kept and set to readonly the generated PDF contains the inserted text in Times New Roman. At least it looks like it. See hexapdf.pdf

When using hexapdf with form flatten (doc.acro_form.flatten(create_appearances: true)) the generated PDF contains the inserted text in a different font(!?)

See hexapdf_flatten.pdf

See textfield.pdf for the test template.

I could use the unflatten version but the PDF template also contains checkboxes and radiobuttons. And unfortunately the radiobuttons can still be edited (changed), at least in Mac Preview(!?)

Best would be to use a non editable PDF. I think, to flatten the form is how it works with hexapdf. But unfortunately the fonts is not kept.

What can we do?

Thanks!

hexapdf_flatten.pdf hexapdf.pdf itext.pdf textfield.pdf

[thomasbaustert]

here is a minimal test script: https://gist.github.com/thomasbaustert/e6c6ff27e6b965abdd8204b7ce2c292d

[gettalong]

• The base document textfield.pdf contains a form field called 'bootstyp'.
• This field references a TrueType font with a basename of 'TimesNewRomanPSMT'.
• This font is not embedded, so it is basically just the name of the font that should be used. Using a non-embedded TrueType font is always a bad idea since now the font that is actually displayed depends on the target device viewing the PDF.
• The itext.pdf file:
  • It opens in Okular but Okular says that there are problems with it (HexaPDF finds at least one issue with its cross-reference table).
  • It uncovers a failure in HexaPDF due to a null value that should have been removed by iText. A fix for this will be in the next release. This might be the reason Okular complains.
  • The filled out and flattened field uses the non-embedded TrueType font. When a PDF viewer encounters this, it tries to find a suitable substitute font to display the value. With Okular in my case this is Nimbus Roman Regular.
• The hexapdf.pdf file uses a substitute font when filling out and rendering the text field because HexaPDF can't use the non-embedded font. The standard font that is used is Helvetica and that is also the one used in this file. This can be customized using the 'acro_form.fallback_font' configuration option.
• The hexapdf_flatten.pdf is the same as the hexapdf.pdf file in terms of fonts used but renders the text field's appearance into the content stream of the page and removes the form data.

So if I'm reading correctly what you need to do is using the 'acro_form.fallback_font' to ensure HexaPDF can work with the correct font.

[thomasbaustert]

I added the font Times New Roman and set it as fallback as follows:

doc = HexaPDF::Document.new(...)
doc.config['font.map'] = {
  'Times New Roman' => { none: font_file('times-new-roman.ttf') }
}
doc.config['acro_form.fallback_font'] = ['Times New Roman', { variant: :none }]
...

The resulting PDF is fine. It embeds the font and when open in a reader the label "Bootstyp" and the text "Bootstyp" are displayed in the same font (Times New Roman). Looks like I have a solution.

But I wonder the following: When I open the hexapdf_flatten.pdf in Acrobat Reader for example, the label "Bootstyp" is display in Times New Roman and the text "Bootstyp" is displayed in Helvetica. This is because hexapdf "changes the font definition" of the text field to Helvetica (fallback), because it cannot use Times New Roman, because the font is not embedded, right?

But the font for the label "Bootstyp" will not be changed. Wouldn't this also have to be changed to Helvetica to be consistent?

It is necessary to "change the font definition" for filled text fields at all? Is it not possible to keep Times New Roman, even it is not embedded in the PDF? And let the reader decide how to display it, but label and text in same font.

[gettalong]

Great that this works for you!

As for your questions:

• You are mixing up two things: The label "Bootstyp" is not a form field, it is rendered on the page itself. This means that a PDF viewer will use the set font. If that font is not embedded, the viewer will choose a substitute font if the font is not available on the system. The field, on the other hand, is actually displayed via a widget annotation and there is information stored in the PDF on how to change the text value and render it.

  As HexaPDF can't use the non-embedded font, the fallback mechanism comes into play and it uses the fallback font as substitute font. So the field definition on how to render the field value stays the same, only the rendered version uses the fallback font. If you edit the PDF later in a PDF viewer and change the value, it will use the Times New Roman font for rendering the value.

  Note that viewers may use additional fonts when rendering a value if the set font doesn't contain all necessary glyphs, e.g. emojis.

• As I wrote above, the definition of which font to use for the form field is not changed at all. When rendering the field, HexaPDF determines that it can't use the set font and chooses a fallback font.

• To use a font stored in a PDF to render some value HexaPDF must understand how to use it. Currently, HexaPDF can only use one of the standard 14 PDF fonts or a fully embedded TrueType font. Other font definitions are currently not supported in terms of rendering form fields (or for text in page content streams).

• As I wrote above, the reader can't really decide anything related to a font, except in the case of non-embedded fonts. In a PDF everything is pre-determined by the application writing the PDF so that the display is the same everywhere. This is also the reason why fonts should be embedded.

• If you are the creator of such a PDF form, make sure that the font is embedded in the PDF. Then you can easily use it for the label and the field.