To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=111272
------- Additional comments from kstrib...@openoffice.org Sat May 1 14:21:03 +0000 2010 ------- Thanks very much @nemeth and @hdu for reporting and investigating this and explaining more about what GetTextBreak() needs to return. I think the long term solution, will need to take into account the expanded text problem in issue 111054, which will exclude the use of Segment::findNextBreakPoint(...), since there is no way to tell it in advance the extra char factor. We definitely, want to avoid recreating a RangeSegment there because of the performance hit, but as @hdu's TODO suggests that could probably be retrieved from the cache. As far as the break weights are concerned, the information from the Graphite GlyphInfo objects is returning a breakweight of +30 for all the letters, which equates to klbLetterBreak, so in theory that should be sufficient, though perhaps findNextBreakPoint requires a range like findNextBreakPoint(mnMinCharPos, gr::klbLetterBreak, gr::klbClipBreak, targetWidth, &fBreakWidth ); I think using gr::klbClipBreak will probably cause problems with SE Asian scripts. I think the biggest problem may be with the fi and fii ligatures. In the case of in-suffi-cient it isn't too bad because the hyphenation point isn't mid-ligature. However, with a word like surfing, it will be more difficult. I've tweaked my patch for issue 111054 to use gr::klbLetterBreak and the best I get is surfi-ng. I'm not sure whether it is possible to get graphite to give a different break-weight mid-ligature. If the GlyphInfo data is used, then it certainly won't, since the info per Glyph. Graphite has the ability to set start and end of line flags when a segment is created. Currently these are not set, because it can cause trailing space to be dropped in position calculations, which gives bad results in some of the other layout methods. In the case of GetTextBreak it might be better to set at least the end of line flag. The Segment::hasLineBoundaryContext() method could perhaps be used to optimize this. However, afaik there is no way to know the start of line context from the current OOo API in VCL. Even if the start and end of line flags were set, it doesn't change the problem with hyphenation based on a hyphenation engine external to Graphite. This would probably require an extension to the Graphite API to allow this information to be passed into the Graphite Text Source. As regards scripts without OOo hyphenators, Myanmar script based languages are one example. In Myanmar spaces are more common at phrase boundaries than word boundaries. The Padauk graphite font has syllable based boundaries, which is an improvement on space based though the best approach uses a combination of a syllable algorithm and a word list. I hope to develop this for Burmese, soon. I have tested it in the past, but the original word list I was given had copyright issues, so I need to switch to another one. My current patch for issue 111054 has a regression for justification, so I won't post an update until I've diagnosed that. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@gsl.openoffice.org For additional commands, e-mail: issues-h...@gsl.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
