Re: white-space-collapse not working in trunk?
On Wed, Feb 15, 2006 at 11:25:03AM +0800, Manuel Mall wrote: 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. I will look at it. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: white-space-collapse not working in trunk?
(moved from fop-users as we are going into the implementation details) Manuel Mall wrote: the shorthand property white-space=pre should be used or its expanded equivalents: linefeed-treatment=preserve white-space-collapse=false white-space-treatment=preserve wrap-option=no-wrap If you do that the bug I was referring to would show because white-space-treatment=preserve is not correctly implemented. 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=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. Is this ok, or am I missing some important detail? Regards Luca
Re: white-space-collapse not working in trunk?
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. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: white-space-collapse not working in trunk?
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
