[
https://issues.apache.org/jira/browse/PDFBOX-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14141920#comment-14141920
]
Maruan Sahyoun commented on PDFBOX-2333:
----------------------------------------
There are no such restrictions that only certain fonts can be used within
forms. At the end the fields appearance stream is not different to other
streams making up the documents content.
There are already text layout mechanisms in fop, odftoolkit and Glen Petersons
table extension for PDFBox. All are ASF licensed. As I’d like to avoid awt
fonts because of the experiences made in the past TextLayout is not what I’d
like to move forward with.
Identity-H and -V are of course allowed. They are not part of the fields value
(as this is either PDFDocEncoding or Unicode) but of the fields appearance.
Initially regular form fields have a simple layout. On that we could build
RichText support followed by XFA field support if we want to.
> Overhaul the apperance generation for PDF forms
> -----------------------------------------------
>
> Key: PDFBOX-2333
> URL: https://issues.apache.org/jira/browse/PDFBOX-2333
> Project: PDFBox
> Issue Type: Improvement
> Components: AcroForm
> Reporter: Maruan Sahyoun
> Fix For: 2.0.0
>
> Attachments: AcroForms-SimpleTextFields.1.8.7.pdf,
> AcroForms-SimpleTextFields.1.8.7.png, AcroForms-SimpleTextFields.pdf
>
>
> The appearance handling for forms in 1.x is limited and does not reflect all
> settings possible for form fields. In addition the current code is not very
> modular and does not follow the box model used for form fields.
> Unfortunately only the basics of form handling are defined in the PDF spec.
> The details like padding of boxes, text placement etc. have to be determined
> by looking at how Adobe forms are generated.
> Update: The file from PDFBOX-2310 has bad rendering which might be related?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
