On Wed, 2006-10-18 at 21:10 -0700, Phil Race wrote: > I had a chat with Doug, one of the principal authors of this code. > > - The behaviour you see was as I noted intended to account for italic > overhang. If removed then it is possible that lines which end > with italic text may be 'clipped' if hard up against some clipping region. > > - However getAdvanceBetween() is supposed to return the logical > advance and did until 1.5 so the behaviour probably should be > reverted. > > - But in part the problem arises because getAdvanceBetween() > is there not to measure substrings. Its there to help you estimate > line break positions. In fact what you are doing is in general > not valid because ligatures, optional or required, and combining > marks mean that drawing the text as substrings may not produce > the same glyphs or measurement. So a few calls to getAdvanceBetween() > might be used to find the break point that most closely fits some > desired width. Then get a TextLayout for the *whole* line. > Also if you want to fit a particular known width line then just > use getLineBreakIndex(). > > - We do not really understand the purpose of getting 'fragments' > It seems to be an unnatural use of this class. Also the many > calls to getAdvanceBetween() particularly as you apparently > use it in the first PNG image, probably contribute significantly > to your performance problems, > > -phil.
Thanks Phil. For an overview of the rationale of fragments in line breaking, see http://defoe.sourceforge.net/folio/knuth-plass.html which summarises the line-breaking algorithm of TeX circa 1981. One obvious optimisation is to select potential breakpoints around the first-fit point for each line, working back and forward from that point until infeasible points are encountered. I'll be looking at this when I get around to optimising. The text boundaries for analysis include word, hyphenation point, font boundaries and locale boundaries (for hyphenation, at least). I use a line-based BreakIterator to develop the initial set of possible breaks, and add the hyphenation points as required. Hyphenation analysis could also benefit from a limiting optimisation as noted above. Ligatures will obviously have to be dealt with specially, but that will involve alternative fragment layout and measurement at breakpoints. The same thing can occur with old-style German and Dutch hyphenation, when the spelling changes at a hyphenation point. The tools that I currently have with Java2D do not fit well with this requirement, as this conversation shows. My best results so far have come from laying out fragments as GlyphVectors, and taking my measurements from them. Inter-word spaces require special treatment, in that they provide the "stretchability" and "squeezeability" of a line. I am experimenting with logical and visual bounds for the measurement of fragments, but within a line the adjustments I make to the spaces tend to subsume such differences. Incidentally, I have been assuming that logical advance included the left and right bearing, whereas visual advance included only the left bearing. Is this correct? Is there a discussion of these concepts anywhere? The current GlyphVector-based system seems to accommodate fragments of italicized text quite well. I think that the requirement I have for paragraph layout will, if anything, become more widespread, so it may be worthwhile thinking about ways to extend 2D text processing to accommodate it. Peter =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
