Skip to main content
Participating Frequently
September 1, 2018
Answered

Confirm the fsType of a fully embedded font in a PDF using Acrobat Pro DC

  • September 1, 2018
  • 3 replies
  • 2472 views

In a (very complicated) attempt to use LaTeX eforms to generate a PDF form that uses a LaTeX font for the forms (see my detailed question here​​), I've managed to fully embed a Type1 font in the PDF, and I'm pretty sure the PostScript of the font has a FSType of 8, so it should be used in the form field. I verified in the postscript of both the font and the embedded postscript before it's sent to Distiller. Distiller creates the PDF and embeds the font without complaints, but I can also use Ghostscript to generate the PDF with similar results. I'm so far unable to get the font to work as a field font.

When I look at the file with Preflight profile "List potential font problems" in Adobe Acrobat Pro DC, I can see all sorts of details about the font I want to use for the form except the fsType information:

Is there a way with Acrobat Pro DC to verify the font is embedded with editing (fsType is 8)?

Also, assuming the fsType carried over from the PostScript to the PDF, do the experts here see any other reason why this font can't be used in the PDF form fields? I was under the impression that Type1 fonts could work, at least according to Embedding fonts in PDF forms and free-text annotations.

Cheers!

This topic has been closed for replies.
Correct answer Test Screen Name

Thanks for pointing out that Adobe had, to an extent, standardised FSType in type 1 fonts, but only when distilling. Doesn't mean it will travel from PFB files. But I think the fsType is a red herring here.

Looking at your file, there is no Augie entry in the Acroform/DR/Font dictionary. I'm a bit rusty on how the content streams of widgets are made, but I'd expect it to be there are you refer to it another stream. There is NO search of the file or system for named fonts when you are filling it in.

3 replies

Legend
September 3, 2018

Watch out for NeedAppearances too, a trick many can’t get right.

Participating Frequently
September 7, 2018

Some progress has been made at this answer on StackExchange.

Test Screen NameCorrect answer
Legend
September 3, 2018

Thanks for pointing out that Adobe had, to an extent, standardised FSType in type 1 fonts, but only when distilling. Doesn't mean it will travel from PFB files. But I think the fsType is a red herring here.

Looking at your file, there is no Augie entry in the Acroform/DR/Font dictionary. I'm a bit rusty on how the content streams of widgets are made, but I'd expect it to be there are you refer to it another stream. There is NO search of the file or system for named fonts when you are filling it in.

Participating Frequently
September 3, 2018

Using your reference to Acroform/DR/Font I found this PDF browser on GitHub - it confirms your answer and also I have a form that works with a TrueType I custom-embedded with XeTeX but have to use Acrobat Reader to re-save it for it to work (IMO, Reader is re-inserting the font into the Acroform element).

Looking at Java PDFBox setting custom font for a few fields in PDF Form - Stack Overflow also confirms that the font must be placed there. Now, to figure out how to make that happen in a LaTeX pipeline... I'm guessing the PDF generation tools aren't that esoteric, but at least I know where to pursue. Thanks again.

Legend
September 3, 2018

FsType is a TrueType attribute found in embedded Truetype font data, though a few writers seem to try to treat it as a type 1 attribute. It isn’t a PDF attribute. Not likely to be the issue anyway. Please share a problem file on your own URL.

Participating Frequently
September 3, 2018

Thanks for the answer. The "Embedding fonts in PDF" section of the document from Adobe I linked to mentions FSType in Type 1 explicitly, so that's why I was taking it seriously as a PDF element.

Here's a link to a zip file (valid for 30 days only) with the PostScript and PDF (the latter generated by Ghostscript; however, if I generate it with Distiller, the results are the same -- the font is not used for the field in Adobe Reader DC even though it shows as fully embedded).