Re: [Silgraphite-devel] Hyphenation issues

[Sharon C. <sha...@si...>]

Martin and I talked about this and I agree that Martin's approach is 
basically a good one. Along with that, it might be a good time to add a 
segment constructor that runs only up to the line-break table and not 
beyond, since this is all that's needed for line breaking. (Of course if 
we do that, there won't be any ligatures, and only one "glyph" per 
character. So changing the way the information is stored might not be 
necessary.) This new constructor could be a good time-saver for 
applications that do line breaking the way OOo does.

Martin Hosken wrote:
> 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
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Silgraphite-devel mailing list
> Sil...@li...
> https://lists.sourceforge.net/lists/listinfo/silgraphite-devel
>