[
https://issues.apache.org/jira/browse/FOP-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244464#comment-17244464
]
Volker Kunert edited comment on FOP-2969 at 12/16/20, 10:27 PM:
----------------------------------------------------------------
It is not clear to me, why the width of the glyph is tested for *in*equality to
zero to decide if it should be reordered. In looking up the width the index of
the glyph in the given text and the index of the glyph in the font are mixed
up.
The different behavior of COMBINING HORN with NotoSans Mono seems to be caused
by another bug, If a font contains an empty position correction for this
glyph, fop does not update the position after reordering the glyphs.
was (Author: [email protected]):
It is not clear to me, why the width of the glyph is used to decide if it
should be reordered. In looking up the width the index of the glyph in the
given text and the index of the glyph in the font are mixed up.
The different behavior of COMBINING HORN with NotoSans Mono seems to be caused
by another bug, If a font contains an empty position correction for this
glyph, fop does not update the position after reordering the glyphs.
> Accented Letters composed of Unicode base letter and combining accent are
> rendered wrong as the first letter of a word.
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: FOP-2969
> URL: https://issues.apache.org/jira/browse/FOP-2969
> Project: FOP
> Issue Type: Bug
> Components: font/opentype, renderer/pdf
> Affects Versions: 2.5, 2.4, trunk
> Reporter: Volker Kunert
> Priority: Major
> Attachments: DIN_SPEC_91379_Sequences-aa-hb-view.pdf,
> DIN_SPEC_91379_Sequences-ab-hb-view.pdf,
> DIN_SPEC_91379_Sequences-ac-hb-view.pdf,
> DIN_SPEC_91379_Sequences-hb-view.txt, DefaultScriptProcessor.java,
> TestFop.java, fop-2969.patch, fop.xconf, test-din-spec-sequences.fo,
> test-din-spec-sequences.fo-patched.pdf, test-din-spec-sequences.fo.pdf
>
>
> E.g. with 0041 030B LATIN CAPITAL LETTER A WITH COMBINING DOUBLE ACUTE ACCENT
> the accent 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.
> If e.g. an "X" is prepended, the sequence is rendered correctly - with the
> exception of the COMBINING HORN which should be at the right side of the base
> letter.
> The tested sequences are used in the following specification:
> DIN SPEC 91379: Characters in Unicode for the electronic processing of names
> and dataexchange in Europe; with digital attachment
> [https://www.xoev.de/downloads-2316#StringLatin]
> [https://www.din.de/de/wdc-beuth:din21:301228458]
> The output of FOP is provided in test-din-spec-sequences.fo.pdf, which is
> created by running TestFop.java that processes test-din-spec-sequences.fo.
> 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]
> The following patch seems to resolve the problem for my test case:
> (delete "{{&& (unscaledWidths[index] != 0").}}
>
> {code:java}
> ---
> ./trunk/fop-core/src/main/java/org/apache/fop/complexscripts/scripts/DefaultScriptProcessor.java
> 2020-09-03 16:20:03.442089088 +0200
> +++
> /home/volker/software/xmlgraphics-fop-trunk/fop-core/src/main/java/org/apache/fop/complexscripts/scripts/DefaultScriptProcessor.java
> 2020-09-03 16:37:40.781775907 +0200
> @@ -151,7 +151,7 @@
> }
> protected boolean isReorderedMark(GlyphDefinitionTable gdef, int[] glyphs,
> int[] unscaledWidths, int index) {
> - return gdef.isGlyphClass(glyphs[index],
> GlyphDefinitionTable.GLYPH_CLASS_MARK) && (unscaledWidths[index] != 0);
> + return gdef.isGlyphClass(glyphs[index],
> GlyphDefinitionTable.GLYPH_CLASS_MARK);
> {code}
> See also PDFBOX-4951
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
