You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "John Hewson (JIRA)" <ji...@apache.org> on 2015/02/04 21:20:36 UTC
[jira] [Comment Edited] (PDFBOX-2661) Implement font fallback for
AcroForms
[ https://issues.apache.org/jira/browse/PDFBOX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305876#comment-14305876 ]
John Hewson edited comment on PDFBOX-2661 at 2/4/15 8:20 PM:
-------------------------------------------------------------
Actually that isn't what's actually going on, there's no unspecified fallback mechanism at work. The PDF page content stream contains the labels for the form fields, and the fields themselves are contained in individual appearance streams.
The font fields each use custom fonts, as specified in their appearance streams. The fonts are named Cour, CoOb, Helv, etc. and are present in the appearance stream's resources, under those names. This is normal and expected and correct.
However, the text labels in the page content stream attempt to use those same font names of Cour, CoOb, Helv, etc. but they are only defined in the individual form field resources, not in the page resources, and so the lookup fails. This is the fault of the PDF file itself. Indeed, if you look at the rendering in Acrobat you'll see that the labels don't appear with custom fonts, they all render as Helvetica. That's because Acrobat isn't doing any special font substitution, it's just falling back to its default font.
was (Author: jahewson):
Actually that isn't what's actually going on, there's no unspecified fallback mechanism at work. The PDF page content stream contains the labels for the form fields, and the fields themselves are contained in individual appearance streams.
The font fields each use custom fonts, as specified in their appearance streams. The fonts are named Cour, CoOb, Helv, etc. and are present in the appearance stream's resources, under those names. This is normal and expected and correct.
However, the labels in the page content stream attempt to use those same font names of Cour, CoOb, Helv, etc. but they are only defined in the individual form field resources, not in the page resources, and so the lookup fails. This is the fault of the PDF file itself. Indeed, if you look at the rendering in Acrobat you'll see that the labels don't appear with custom fonts, they all render as Helvetica. That's because Acrobat isn't doing any special font substitution, it's just falling back to its default font.
> Implement font fallback for AcroForms
> -------------------------------------
>
> Key: PDFBOX-2661
> URL: https://issues.apache.org/jira/browse/PDFBOX-2661
> Project: PDFBox
> Issue Type: Improvement
> Components: AcroForm
> Affects Versions: 1.8.8, 2.0.0
> Reporter: Maruan Sahyoun
> Fix For: 2.1.0
>
> Attachments: FontTest.java, Fonts.pdf
>
>
> There are forms where the font specified in the fields default appearance is not pointing to the correct fields or forms resources entry. Adobe Reader/Acrobat have a (unspecified) fallback mechanism to resolve such missing fonts.
> We should be ably to come up with a similar solution.
> A sample of such an issue can be found in PDFBOX-1234
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org