https://issues.apache.org/bugzilla/show_bug.cgi?id=45097
--- Comment #16 from Andreas L. Delmelle <[EMAIL PROTECTED]> 2008-11-26 11:10:50 PST --- (In reply to comment #15) <snip /> Thanks for the rectification, although I wasn't really wrong. At most, not accurate enough. ;-P > <snip/> > > For 2), I'm thinking of very extreme (and highly unusual) cases, where it > > becomes necessary to choose 'a' break, but the choice is between white-space > > characters only. If white-space treatment is "preserve", a portion of > > white-space should, strictly speaking, be pushed to the next line, and > > influence alignment there... but ideally, if it all fits on one line, that > > possibility should obviously be preferred above all else. > > This is probably the biggest issue. This may require to handle a sequence of > white spaces in its whole instead of each character individually. Sorry, I > don't have enough energy ATM to look at this issue into more details. Being > sure that every combination of white space options (white-space-treatment, > white-space-collapse, linefeed-treatment...) is handled correctly requires an > extensive study. I was thinking about introducing a special type of auxiliary glue, with the possibility to break it in two at a position that is not fixed at the time the element is generated. (more like a combination of two glues, whose combined width is known, but not the width of the two individual elements.) The LineLM would then treat this as a whole, but not an unbreakable whole, see how big a portion it can fit on one line, and insert an auxiliary box for the remaining width (rather than /always/ adding that auxiliary box in the TextLM when white-space-treatment='preserve'). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
