Re: problem with layout in ICU 2.6

Hello Jens,

The defaultCharMapper does not remove the CR, it replaces it w/ a 0xFFFF 
character. Later on, LEFontInstance::mapCharToGlyph() maps the 0xFFFF 
character to a 0xFFFF glyph, also called the "deleted glyph." The char 
to glyph map should have an entry for this glyph.

I seem to recall that one of the patches OO makes to the LayoutEngine 
has to do w/ how deleted glyphs are handled; perhaps this is what's 
causing the problem?

If that's not the problem, I'll need more detailed information about 
what you see happening.

Regards,
Eric Mader
IBM GCoC - San José
5600 Cottle Road  M/S 50-2/B11
San Jose, CA 95193

Jens Herden wrote:
> Hello,
> 
> I am working on backporting the Khmer layout engine to ICU 2.6 because Open 
> Office 2.0 will use this version of ICU in its code and I would like to have 
> Khmer supported there.
> 
> I get a problem during my test which I can not solve and that is not present 
> in the latest ICU. 
> Every time a CR character is in a run of Khmer characters this character is 
> filtered in the charMapper so that the result is one character shorter then 
> the input. But later on the code creates mappings between characters and 
> glyphs and here the filtered character is skipped and a not entry is created 
> in the map for the CR. This leads to a problem in ParagraphLayout::appendRun, 
> because here the code tries to find the left and right glyph what fails 
> because of the missing entry in the map. 
> 
> Is this a known bug or did I made a mistake in backporting the Khmer layout 
> engine? 
> 
> Sorry for bothering you with a question about an old version.
> 
> Jens