[
https://issues.apache.org/jira/browse/PDFBOX-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18052251#comment-18052251
]
Larry Lynn commented on PDFBOX-6149:
------------------------------------
PdfSpacingTestUsingPdfBox.java is the driver code used to produce the output
PDF.
Both charspacing_currentcode-2.0.35.pdf and charspacing_currentcode-3.0.6.pdf
are outputs produced by the same driver code. They are produced with PDFBox
2.0.35 & PDFBox 3.0.6, respectively.
the-diff.pdf is a visual difference between the output produced by the 2
different versions of PDFBox. I made this diff with a utility called diff-pdf,
[https://vslavik.github.io/diff-pdf/.|https://vslavik.github.io/diff-pdf/] It
is an open-source tool with a GPL license. On my machine, In installed it with
homebrew. Installation instructions will vary by platform.
> PDFBox makes PDF with different text placement 2.0.x vs. 3.0.x
> --------------------------------------------------------------
>
> Key: PDFBOX-6149
> URL: https://issues.apache.org/jira/browse/PDFBOX-6149
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, PDModel
> Affects Versions: 3.0.6 PDFBox
> Environment: PDFBox 3.0.6, PDFBox 2.0.35, Java 25, unix/Darwin,
> Redhat (Corretto)
> Reporter: Larry Lynn
> Priority: Major
> Attachments: PdfSpacingTestUsingPdfBox.java,
> charspacing_currentcode-2.0.35.pdf, charspacing_currentcode-3.0.6.pdf,
> the-diff-enlarged.png, the-diff.pdf
>
>
> We've encountered some text placement issues when creating a PDF using PDFBox
> 3.0.5 and the GoogleSansText.ttf font. We've done version bisection and
> retested on the older PDFBox 2.0.x version and confirmed different PDF box
> output using the same code and the same font. Therefore, we suspect a
> regression introduced by the 2.x to 3.x major version bump.
>
> Text placement of a footnote anchor is above main body text in 3.x. At first
> glance, this looks like a superscript problem, but on closer examination, it
> looks like the baseline string has expanded in width. Horizontal differences
> between characters suggested a kerning problem to us. However, my colleague
> Naga did some exploratory testing and loaded the font with PDTrueTypeFont()
> instead of {color:#000000}PDType0Font{color}(). The problem did not
> reproduce with PDTrueTypeFont, however, that loader also does not support
> font sub-setting, which is a killer feature for us. This led us to believe
> that a subsetting regression might be in play.
>
> Our internal continuous integration regression tests produce 100+ PDFs with
> various combinations of different fonts. We detected no other changes when
> we migrated from PDFBox 2.0.34 to 3.0.5. Therefore, I think that the
> discrepancy is specific to the interaction of PDFBox 3.x with this particular
> font, rather than any sort of general breakage.
>
> I will provide sample code to demonstrate this issue, along with a protected
> version of the font. I also have sample output which I will upload. I've
> tested on the highest versions of the 3.x and 2.x branches to demonstrate a
> difference.
>
> Thank you again for all your hard work on this awesome library.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
