xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Volker Kunert (Jira)" <j...@apache.org>
Subject [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.
Date Wed, 16 Dec 2020 22:28:00 GMT

    [ 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: vk.lists@gmail.com):
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)

Mime
View raw message