From: Eric M. <ma...@jt...> - 2005-02-01 20:02:00
|
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 |