[
https://issues.apache.org/jira/browse/PDFBOX-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18052289#comment-18052289
]
Tilman Hausherr commented on PDFBOX-6149:
-----------------------------------------
Do this:
{code:java}
TrueTypeFont ttf = new TTFParser().parse(new
RandomAccessReadBufferedFile(file));
ttf.setEnableGsub(false);
PDFont font = PDType0Font.load(doc, ttf, true);
{code}
What happened with your file is that the bengali complex script replacement was
used for "(" and ")" because these are different for bengali.
> 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: GoogleSansText.ttf.zip, 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, but 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.
>
> I've uploaded a copy of the TTF for the problem font file inside of a
> password protected zip archive. I've sent access info to open the password
> protected zip archive via a private channel.
>
> 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]
