[
https://issues.apache.org/jira/browse/PDFBOX-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14527633#comment-14527633
]
John Hewson edited comment on PDFBOX-2333 at 5/5/15 12:29 AM:
--------------------------------------------------------------
I took a look at AppearancePrimitivesComposer because I wasn't really sure
what "primitives" or "composer" meant, as the PDF spec contains neither of
those words. Looking at the code I saw it was copied and pasted from
PDPageContentStream, so then I understood what AppearancePrimitivesComposer
actually does: it writes graphical operators to a content stream, just like
PDPageContentStream.
I decided to see if it was possible to simply use PDPageContentStream, only
without a "page". The answer is yes, so I've removed
AppearancePrimitivesComposer and replaced its usage with PDPageContentStream.
(We might now want to think about renaming PDPageContentStream so that it
doesn't have "page" in the name, but that's a separate issue). The nice thing
is that the 160 or so lines of PDPageContentStream are now replaced with 8 or
so lines in PDPageContentStream and there's no more copy/pasted code.
There's one aspect which requires your attention, which is the way that the
font was being set has now changed. The PDF spec says of DA strings that "At a
minimum, the string shall include a Tf (text font) operator along with its two
operands, font and size." yet the code in AppearancePrimitivesComposer never
emitted a Tf operator. Note that it's illegal to use any text operations
without first setting the font, so it seems like there's something wrong with
the previous code. [~msahyoun], can you take a look at the new code which sets
fonts on the following lines and make sure that it's ok:
- AppearanceGeneratorHelper, line 309
- PlainTextFormatter, line 173
- PlainTextFormatter, line 250
It's no problem to tweak the new code to handle fonts slightly differently - I
just need to understand what that difference is, if any.
was (Author: jahewson):
I took a look at AppearancePrimitivesComposer because I wasn't really sure
what "primitives" or "composer" meant, as the PDF spec contains neither of
those words. Looking at the code I saw it was copied and pasted from
PDPageContentStream, so then I understood what AppearancePrimitivesComposer
actually does: it writes graphical operators to a content stream, just like
PDPageContentStream.
I decided to see if it was possible to simply use PDPageContentStream, only
without a "page". The answer is yes, so I've removed
AppearancePrimitivesComposer and replaced its usage with PDPageContentStream.
(We might now want to think about renaming PDPageContentStream so that it
doesn't have "page" in the name, but that's a separate issue). The nice thing
is that the 160 or so lines of PDPageContentStream are now replaced with 8 or
so lines in PDPageContentStream and there's no more copy/pasted code.
There's one aspect which requires your attentions, which is the way that the
font was being set has now changed. The PDF spec says of DA strings that "At a
minimum, the string shall include a Tf (text font) operator along with its two
operands, font and size." yet the code in AppearancePrimitivesComposer never
emitted a Tf operator. Note that it's illegal to use any text operations
without first setting the font, so it seems like there's something wrong with
the previous code. [~msahyoun], can you take a look at the new code which sets
fonts on the following lines and make sure that it's ok:
- AppearanceGeneratorHelper, line 309
- PlainTextFormatter, line 173
- PlainTextFormatter, line 250
It's no problem to tweak the new code to handle fonts slightly differently - I
just need to understand what that difference is, if any.
> 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
> Affects Versions: 2.0.0
> Reporter: Maruan Sahyoun
> Assignee: Maruan Sahyoun
> Priority: Critical
> Fix For: 2.0.0
>
> Attachments: AcroForms-SimpleTextFields.1.8.7.pdf,
> AcroForms-SimpleTextFields.1.8.7.png, AcroForms-SimpleTextFields.pdf,
> AlignmentTests-post1633495.pdf, AlignmentTests-pre1633495.pdf,
> MultilineTests-prePatch.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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
