[
https://issues.apache.org/jira/browse/PDFBOX-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18104329#comment-18104329
]
Maruan Sahyoun commented on PDFBOX-4951:
----------------------------------------
Could you give a high-level description of the change you're proposing? To
confirm we're on the same page: the new font class wraps the current font and a
GlyphLayoutProcessorPlain/Simple internally, so the existing getStringWidth
calls in PlainText stay as they are. One thing I'd like to understand —
getStringWidth(String) has no fontSize or bidiLevel parameter, but the
processor needs both. Where would those come from when the wrapping font class
delegates? And would this font class be the instance already used everywhere a
PDFont is resolved for the field (e.g. via PDResources), so call sites outside
PlainText get this too, or is it scoped to the appearance-generation path
specifically?
> Sequences of DIN SPEC 91379 with combining letters are rendered incorrectly
> ---------------------------------------------------------------------------
>
> Key: PDFBOX-4951
> URL: https://issues.apache.org/jira/browse/PDFBOX-4951
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 2.0.21
> Reporter: Volker Kunert
> Assignee: Tilman Hausherr
> Priority: Major
> Fix For: 3.0.9 PDFBox, 4.0.0
>
> Attachments: Bildschirmfoto_2026-07-07_08-38-04.png,
> DIN_SPEC_91379_Sequences-aa.pdf, DIN_SPEC_91379_Sequences-ab.pdf,
> DIN_SPEC_91379_Sequences-ac.pdf, DIN_SPEC_91379_Sequences.txt,
> DefaultScriptProcessor.java, DejaVuSans.ttf, DoGlyphLayoutBidi.pdf,
> DoGlyphLayoutDinSpec91379.pdf, DoGlyphLayoutDinSpec91379Form.pdf,
> DoGlyphPositionBengali.pdf, ExamplePdfboxFopPos-By-Tilman.pdf,
> ExamplePdfboxFopPos.java, ExamplePdfboxFopPos.pdf,
> ExamplePdfboxFopPosForm.java, ExamplePdfboxFopPosForm.pdf,
> FiraCode-Regular.ttf, FontForge-Lohit-Bengali.png, TestPdfbox.java,
> TestPdfboxFop2.java, TestPdfboxFop2.pdf, TestPdfboxJava2D.java,
> TestPdfboxJava2D.pdf, bengali.fo, bengali.pdf, bidi-1.png, bidi-2.png,
> bidi.fo, bidi.pdf, bidi.png, config.xml, dejavu-sequences.png,
> example-PDFBOX-3147-NotoSansThaiLooped-Regular.png,
> image-2026-05-23-16-16-53-442.png, image-2026-05-23-16-17-28-172.png,
> image-2026-05-26-16-49-45-529.png, image-2026-07-04-21-37-03-606.png,
> image-2026-07-04-21-37-35-370.png, kerning.fo, kerning.pdf,
> ligatures-kerning.png, patch-2020-10-02.txt, pdfbox.patch, pdfbox.pdf,
> screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> Accented Letters composed of Unicode base letter and combining accent are
> rendered wrong. E.g. with 0041 030B LATIN CAPITAL LETTER A WITH COMBINING
> DOUBLE ACUTE ACCENT the accent appears at the right hand side of the letter
> A, not above the letter A.
> The position is wrong for most of the sequences defined in the following spec:
> DIN SPEC 91379: Characters in Unicode for the electronic processing of names
> and data
> exchange in Europe; with digital attachment
> [https://www.xoev.de/downloads-2316#StringLatin]
> [https://www.din.de/de/wdc-beuth:din21:301228458]
>
> The correct rendering should look like the output of hb-view 2.6.8, see files
> DIN_SPEC_91379_Sequences*.pdf.
> The output of PDFBox is appended in pdfbox.pdf, which is created by running
> TestPdfbox.java. The sequences are read from file
> DIN_SPEC_91379_Sequences.txt.
>
> Font used for testing: NotoSansMono-Regular.ttf, see
> [https://www.google.com/get/noto/]
> download:
> [https://noto-website-2.storage.googleapis.com/pkgs/NotoSansMono-hinted.zip]
> See also FOP-2969
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
