[
https://issues.apache.org/jira/browse/PDFBOX-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306826#comment-14306826
]
Tilman Hausherr commented on PDFBOX-2661:
-----------------------------------------
My understanding of this after looking at the file, and looking at "CoOb":
There is no resource with that name.
{code}
6 0 obj
<<
/Rect [200.0 781.8898 400.0 801.8898]
/DA (/CoOb 11 Tf 0 g)
/FT /Tx
/Type /Annot
/Subtype /Widget
/T (CoOb)
>>
endobj
{code}
Initially it doesn't matter because the field is empty. The field labels are
displayed in the default font in Adobe Reader.
In Adobe Reader, when writing to that field the text appears in the field in
the expected fallback font, and when saving to that file, Adobe Reader adds a
resource within "/AP". That one maps /CoOb to /Courier-Oblique.
So there is a fallback mechanism but only for the field content font.
So the actual problem is: what would happen if PDFBox writes in the CoOb field?
> 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
> 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-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
