From: Martin H. <mar...@si...> - 2010-05-03 11:04:48
|
Dear Keith, > Another issue has come up with Graphite fonts in OpenOffice, this time > concerning hyphenation. > http://www.openoffice.org/issues/show_bug.cgi?id=111272 > OpenOffice has its own hyphenation dictionaries and afaik Graphite > Western fonts don't have support for dictionary based hyphenation in > them. The case is complicated by the current OpenOffice API not giving > access to start and end of line context flags, but even if it did, I'm > not sure it would help. Is there a case for break weight information > being added to the ITextSource interface? How would we deal with the fi > ligature in a word like surfing which should be hyphenated surf-ing? The > GlyphInfo object gives breakweight information per ligature, so I'm not > sure how that could be returned for klbHyphenBreak mid ligature. Firstly, when we were thinking through the whole hyphenation, line breaking issue, we decided that it was not Graphite's job to be a sophisticated (read hyphenating) line breaker. If an application wanted to do sophisticated line breaking then it would have to render a range segment and decide on the break positions itself from the information it could glean (intended to be sufficient) from the range segment. It seems, though, that you have found a bug in that information, in that Segment::getBreakWeight assumes that all ligatures are indivisible at least down to clipBreak. It is, as you say, implemented by storing breakweight info within the glyph info. But that isn't really the correct solution. The correct solution is to store it against the character. This isn't going to be easy to fix given we have no concept of a character object within the engine. One approach would be to use an array of breakweights in a segment, one per char. Or alternatively to store breakweights for all ligature components. Anyway, whichever way we implement it, it's not going to happen overnight. If we do fix this and getBreakWeight and findNextBreak are implemented correctly to handle ffi etc. would that be a sufficient solution do you think? GB, Martin |