Apache OpenOffice (AOO) Bugzilla – Issue 73563
SortGlyphItems and glyph fallback for Lohit Bengali Assam text
Last modified: 2017-05-20 11:31:37 UTC
Four attachments, demoproblem-small.odt pass demoproblem-small2.odt fail demoproblem.odt fail screenshot.png: pass beside fail X (Y) is where X is maLinearPos.X() and (Y) is mnGlyphIndex of each element demoproblem-small2.odt debug dump of SortGlyphItems: Start positions of count of 3 are: 2219 (437) 2177 (131) End positions of count of 3 are: 2177 (131) 2219 (437) Start positions of count of 3 are: 25 (437) 24 (131) End positions of count of 3 are: 24 (131) 25 (437) Start positions of count of 3 are: 2219 (437) 2177 (131) End positions of count of 3 are: 2177 (131) 2219 (437) Start positions of count of 3 are: 25 (437) 24 (131) End positions of count of 3 are: 24 (131) 25 (437) demoproblem-small.odt debug dump of SortGlyphItems: Start positions of count of 4 are: 2219 (437) 2177 (3) 3174 (131) End positions of count of 4 are: 2177 (3) 2219 (437) 3174 (131) Start positions of count of 4 are: 25 (437) 24 (3) 35 (131) End positions of count of 4 are: 24 (3) 25 (437) 35 (131) Start positions of count of 4 are: 2219 (437) 2177 (3) 3174 (131) End positions of count of 4 are: 2177 (3) 2219 (437) 3174 (131) Start positions of count of 4 are: 25 (437) 24 (3) 35 (131) End positions of count of 4 are: 24 (3) 25 (437) 35 (131) So I "fail" when glyph 437 gets sorted before 131 (Lohit Bengali is in fonts-bengali on fedora) In the "pass" case the characters are all in "Lohit Bengali", and so the whole thing gets processed in one chunk. In the 2nd case glyph replacement takes place and in the font fallback Lohit Bengali is detected as the font for the missing characters, but space is not missing from the Nimbus font so there's no request for a space glyph. So pass: 2219 (437) 2177 (3) 3174 (131) -> 24 (3) 25 (437) 35 (131) is fail: 2219 (437) 2177 (131) -> 24 (131) 25 (437) If SortGlyphItems sorts into visual order then the pass results look strange to me as (3) is the space glyph which I wouldn't have expected to see at the start of the visual sequence.
Created attachment 42230 [details] demoproblem-small.odt
Created attachment 42231 [details] demoproblem-small2.odt
Created attachment 42232 [details] demoproblem.odt
Created attachment 42233 [details] screenshot
cmc->hdu: I'm unsure whether this will be easy to reproduce/consider because I've the proposed fontconfig glyph and font replacement stuff active in these builds, so feel free to dismiss this. Given that roughly the glyph replacement the sequence MISSING NOTMISSING MISSING results in a multisallayout of 0) X NOTMISSING X 1) REPLACEMENT X REPLACEMENT it might be the case that somehow rejigging things to give 0) X NOTMISSING X 1) REPLACEMENT X X 2) X X REPLACEMENT might be another way to resolve this if SortGlyphItems is doing what is expected
Thank you for the interesting test cases! Have you had a look at the problem with a more recent build >=SRC680_m197, which integrated the CWS icuupgrade, too?
no not tested with m197 yet, but this output is with system-icu which is 3.6 and a backport of that icuupgrade workspace to 2.1.0
set target 3.x
Reset assigne to the default "issues@openoffice.apache.org".