https://issues.apache.org/bugzilla/show_bug.cgi?id=45097
--- Comment #9 from Andreas L. Delmelle <[EMAIL PROTECTED]> 2008-05-30 00:26:57 PST --- (In reply to comment #8) > (In reply to comment #7) > > ...if the line-breaking algorithm > > has a choice of either breaking before or after a space, it will always > > break > > before it. > > Here's where I think our opinions might differ. I believe it should break > after the space. Oh, but the result /is/ correct, strictly speaking. A bit unexpected, maybe, but definitely not a bug. The point is well taken though. I've been looking at the related code, and was beginning to wonder... This is more meant for the layout-specialists, but using simple start-alignment, the sequence currently generated for a preserved space consists of: - a glue - a penalty p=0 - a glue - an auxiliary box w=0 - a penalty p=INFINITE - a glue >From a higher-level point of view (the LineLayoutManager) a break on the first penalty will always be favored over a break on the second, hence why I think the algorithm chooses to break before the space rather than after. With a preceding and following word, the above sequence would be enclosed by boxes corresponding to those words. If the break /has/ to be somewhere in between the two word-boxes, the preserved space in between always appears at the start of the next line. Again, not incorrect, but not the most elegantly looking outcome either. Actually, it's even slightly worse. Given a sequence of those preserved spaces, as many as possible will be placed on the line as trailing white-space. That is: all but the very last one. The zero-penalty appears to be always favored as the last break in the sequence... <snip /> > I searched in the spec for quite awhile trying to find where it clearly says > which line-area gets the whitespace in a wrapping block-area, but I couldn't > find it. The closest I found was this, which unfortunately is a little > ambiguous. > Indeed, the rules about where exactly line-breaks are supposed to end up are not defined by XSL-FO itself. FOP uses Unicode UAX#14 (http://www.unicode.org/reports/tr14/) as reference for the most part, which does not explicitly forbid a break before a space (although it is discouraged, IIC) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
