You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Volker Kunert (Jira)" <ji...@apache.org> on 2020/10/05 07:34:00 UTC
[jira] [Comment Edited] (FOP-2969) Accented Letters composed of
Unicode base letter and combining accent are rendered wrong as the first
letter of a word.
[ https://issues.apache.org/jira/browse/FOP-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206185#comment-17206185 ]
Volker Kunert edited comment on FOP-2969 at 10/5/20, 7:33 AM:
--------------------------------------------------------------
I added a patched version of DefaultScriptProcessor.java and the PDF produced with this patch: expected-din-spec-sequences.fo.pdf which shows the accents at correct positions - with the exception of the COMBINING HORN which should be at the right side of the base letter, compare the output of hb-view: DIN_SPEC_91379_Sequences-??-hb-view.pdf
was (Author: vk.lists@gmail.com):
I added a patched version of DefaultScriptProcessor.java and the PDF produced with this patch: expected-din-spec-sequences.fo.pdf which shows the accents at correct positions.
> 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: DefaultScriptProcessor.java, TestFop.java, expected-din-spec-sequences.fo.pdf, fop.xconf, test-din-spec-sequences.fo, 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.
> 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 dirty 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)