> On Tue, Feb 14, 2006 at 10:26:52AM +0100, Luca Furini wrote: >> >> In order to preserve all spaces, we could use the elements that are now >> generated for a nbsp: >> box w=0 >> penalty inf >> glue (elastic or not, according to the alignment) >> >> They are not suppressed and they do not allow a break, so I think they >> should fit quite well this situation too, when white-space-treatment = >> "preserve" and wrap-option="no-wrap". > > If wrap-option="no-wrap", cannot we somehow avoid the whole linebreak > calculation? Each line is a Knuth paragraph and creates a single line. > >> If wrap-option="wrap", however, we must add some penalties in order to >> allow a break between spaces; we must be careful, as if there are 3 >> spaces >> between two words, there are 4 possible breaks (ignoring, at the moment, >> unicode breaking rules), so we just cannot add a penalty before or after >> the other elements. > > Isn't it so that in the case of white-space-treatment="preserve" the > line breaks are between the spaces instead of on them? Then for a___b, > where an underscore indicates a space, I would construct > > box(a) p box(0) p(inf) glue p box(0) p(inf) glue p box(0) p(inf) glue p > box(b) > > with possible line breaks at the p. >
The above sequence only covers the simplest case. The moment we have justification and/or border padding it gets more complicated. Some time ago (mid Nov 2005) I started a WIKI page http://wiki.apache.org/xmlgraphics-fop/LineBreaking where I attempted to document the different scenarios with respect to line breaking and Knuth element generation. I identified the following different cases: 1. Non breaking / non elastic 2. Non breaking / elastic space 3. Break / non elastic 4. Break / non elastic / add character if break 5. Break / non elastic / remove if not break 6. Break / non elastic / removable 7. Break / elastic / non removable 8. Break / elastic / removable Your case above is basically case 7.). May be this is a trigger for those interested (Luca?, Simon?, ...) to review this WIKI page and may be suggest clarifications, corrections, restructuring, .... I still think it would be valuable to a) Capture all the different break scenarios (may be the cases 1. to 8. above are not complete or can be simplified) b) Document the relevant Knuth sequences applying to each identified break scenario Once we have that converting it into code should be fairly straightforward. > Simon > > -- > Simon Pepping > home page: http://www.leverkruid.nl > Manuel
