In Arabic or Hebrew (all RTL scripts) getGlyphToCharMap returns wrong mapping

Description

In Arabic or Hebrew (supposedly in all RTL language scripts) getGlyphToCharMap returns wrong mapping. The mapping is incorrect in case of a wrapping. I checked it on the example "layout" delivered with ICU. When I change size of the window the text is wrapping from single line to many other lines. The problem appears only on RTL languages that the mapping for first indexes line is at the end in Unicodes. Below I tried to visualize the problem in the tables in the following format [number_glyph_in_single_line]:[glyph_index]:[mapping_getGlyphToCharMap_for_the_glyph]

Correct mapping (breaking line is not used)
0:915:10
1:942:9
2:1012:8
3:976:7
4:956:6
5:991:5
6:909:4
7:3:3
8:916:2
9:991:1
10:909:0

Incorrect mapping (breaking line is used)
0:3:10
1:916:9
2:991:8
3:909:7
0:1012:6
1:976:5
2:956:4
3:991:3
4:909:2
0:915:1
1:942:0

Incorrect mapping should be correct as below:
0:3:3
1:916:2
2:991:1
3:909:0
0:1012:8
1:976:7
2:956:6
3:991:5
4:909:4
0:915:10
1:942:9

I attached paragraph_bad_mapping.PNG, paragraph_good_mapping.PNG, Sample.txt and FontMap.GDI files

Activity

Show:
TracBot
July 1, 2018, 12:12 AM
Trac Comment 4 by eric—2007-11-06T23:47:30.000Z

I'm reopening this because Alexis Tamas at STG Interactive found that the fix did not work in all cases. In fact, the original fix only works if the whole paragraph is right to left text.

TracBot
July 1, 2018, 12:12 AM
Trac Comment 5 by eric—2007-11-14T19:11:58.000Z

This bug is now ready for review.

TracBot
July 1, 2018, 12:12 AM
Trac Comment 7 by —2016-10-05T23:17:06.979Z

Milestone 3.9.1 deleted

Fixed

Assignee

TracBot

Reporter

TracBot

Components

Labels

None

Reviewer

None

Priority

major

Time Needed

Days

Fix versions