0

I just started a project for a personalized bookkeeping software where I fill in the results in a premade PDF form. I have everything working correctly but in one of the forms the text entered with iText7 has a different font then fields that are calculated atomatically or entered manually. When I click in the form field of the resulting pdf the font changes from the displayfont to the real font.

Is there a way to set the default font used by iText7 to fill in fields? This isn't a problem on the other forms so I'm not sure how to handle this. I use the SetValue(string value, string display) method to set the text because I need currency formatting.

EDIT: I have other forms that don't have this problem. I checked out the font on the fields on those forms and get this result:

{PdfFont{fontProgram=Times-Roman}}
embedded: false
fontEncoding: {iText.Kernel.Font.DocFontEncoding}
fontProgram: {Times-Roman}
forceWidthsOutput: false
newFont: false
notdefGlyphs: Count = 0
shortTag: {byte[256]}
subset: false
subsetRanges: null
toUnicode: null

The form with the issues has the following font properties on the fields:

{PdfFont{fontProgram=Helvetica}}
embedded: false
fontEncoding: {iText.IO.Font.FontEncoding}
fontProgram: {Helvetica}
forceWidthsOutput: false
newFont: true
notdefGlyphs: Count = 0
shortTag: {byte[256]}
subset: true
subsetRanges: null
toUnicode: null

The bad form uses a new font whereas the good form uses the font it is supposed to. I've tried the following (field = fieldname, value = text for the field):

PdfAcroForm form = PdfAcroForm.GetAcroForm(PdfDocument, true);
PdfFont font = PdfFontFactory.CreateFont(StandardFonts.TIMES_ROMAN);
PdfFormField formField = form.GetField(field.ToString());
formField.SetFont(font);
formField.SetValue(value);

Sadly this does nothing and I still end up with fields that render as Helvetica. When I click on a field it turns to Times Roman but that was always the case.

I checked both forms with RUPS and they do look different: 1 = bad pdf, 2 = good pdf

On the bad PDF the Acroform is indirect while on the good form acroform is a proper dictionary. Also the acroform on the bad pdf doesn't contain default resources containing a font dictionary. I'm not really up to speed on Dictionaries and such so if anyone can point me in the direction on how to fix this I'd be grateful.

mkl
  • 90,588
  • 15
  • 125
  • 265
MicaH
  • 1
  • 2
  • Itext does not execute javascript associated with these fields. Thus, any formatting done by javascript are not applied in itext generated appearances. Some other pdf libraries prevent your issue by not generating an appearance at all if formatting javascript is present. This can result in issues in other use cases, though. – mkl Apr 12 '20 at 14:25
  • I'm pretty sure the javascript doesn't format the font. It only does format the numbers to display as currency and some fields add up other field values to display the sum of the values. I used PDFSharp before switching to iText, the problem didn't occur then. – MicaH Apr 14 '20 at 15:03
  • Please share the pdf in question. – mkl Apr 14 '20 at 20:43
  • That's not possible. I'm under strict orders not to share it with anyone. I'm just looking for someone to point me in the right direction. I've checked the pdf with Rups and it is like I said: there are only formatting scripts for currency and for adding up fields. The standard font is Helvetica but Itext fills in the displayvalue with arial (I think). The regular value is indeed Helvetica. I tried setting the font after setting the values, but that doesn't work. In fact it makes it worse: the regularvalue becomes the displayvalue. – MicaH Apr 15 '20 at 06:42
  • I'm afraid without the PDF in question this is fruitless guesswork. Consider making this a support call with iText and sharing the PDF subject to a NDA. – mkl Apr 15 '20 at 09:08
  • I got my fonts mixed up. The font I want is Times Roman and the one I get is Helvetica. The forms without problems have a Times Roman font on the field, the one with problems has the Helvatica font. I'm updating the original description. @mkl: please check out the new description and see if this means something to you. – MicaH Apr 16 '20 at 07:49
  • I'm afraid it still sounds like either some JavaScript effect or some error in the PDF. Different appearances after clicking on the field may indicate that one appearance is generated and embedded by iText while the other is generated by the PDF viewer. But there likely is a reason for iText using Helvetica. Different PDF processors may yield different results, e.g. they may not create an appearance to start with, so the viewer always creates the appearance. You may try to use `form.SetNeedAppearances(true)` to make the viewer always regenerate appearances, but that only would be a work-around – mkl Apr 16 '20 at 08:31
  • @mkl: thank you for your suggestions. I've actually tried the SetNeedAppearances method but that didn't work. However, I did find out that the bad PDFs acroform is indirect and doesn't contain default resources. Check out my latest edits and please let me know if you know of a way to fix this. – MicaH Apr 16 '20 at 11:54
  • Not containing default resources might be the issue because those resources are where the default appearance fonts must be defined according to the PDF specification. Adobe Reader additionally interprets certain names to refer to certain fonts but that behavior is not according to the PDF specification. You may want to try and generate default resources when confronted with a PDF without any. – mkl Apr 16 '20 at 17:25
  • I generated default resources with only the correct font and iText simply added the Helvetica font to it and used that anyway. I've given up. I've switched back to PDFSharp and use iText only to check and correct forms that don't have the fields referenced in the acroform fields set on the document root level. Thanks for your input, @mkl. – MicaH Apr 18 '20 at 14:20

0 Answers0