From: Keith S. <str...@fa...> - 2010-05-05 06:43:49
|
Martin Hosken wrote: > 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. You seem to be saying that Graphite was designed so that applications requiring hyphenators are expected to do it themselves, without passing the break weight information to graphite for the engine to try to merge with its own information. > 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. I guess it would only become worth while if a script is found which needs ligatures broken for line-breaking, but would not benefit from a hyphenator or more sophisticated external algorithm. Presumably, no existing Graphite font has found such a need. I haven't used Segment::getBreakWeight itself since it is an undocumented part of the API and perhaps deprecated. It also gives confusing results since the fBreakBefore flag only refers to the glyph before or after the character index. Although the return type is LineBrk it is actually signed, it is not combining break weights from preceding and following glyphs to determine whether the preceding positive (if present) or following negative break weight (if present) wins. > 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? > I think getBreakWeight would be the more usable method if it was well documented, since it allows all the break positions to be retrieved. If this change was made, it might be worth considering the case of [letter][space] - currently the break weights don't allow a break between them, only following the space. For the original OpenOffice issue, we have a work around, but it will mean that any scripts currently relying on Graphite for line breaking will need to have an OpenOffice line breaker implemented, perhaps as an OOo extension. Keith |