I have taken my time, but here is my reaction to the Wiki page on white space handling. In addition, I have written my own view on the XSL-FO spec's handling of white space in a Wiki page.
Step 2. Refinement: white-space-collapse ======================================== Issue 1. The spec intentionally addresses only XML white space, because only such white space is manipulated by editors to obtain pretty printing. Issue 2. The spec intentionally addresses only the collapse of white space around linefeed characters, because only such white space is manipulated by editors to obtain pretty printing. Even if linefeed characters indicate real line breaks and are preserved, it is possible that the editor has introduced sequences of XML white space characters for pretty printing. Issue 3. White-space-collapse is formulated in terms of space characters which do not generate an area. That is similar to the space resolution rules, where space specifiers get a zero width. Since there is no merging of white space glyph areas into a single area, there is no contradiction with the condition for glyph merging in section 4.7.2. The space glyph area that does generate an area, determines the traits of that area. Step 3. Line building: white-space-treatment and suppress-at-linebreak ====================================================================== I agree that the references to the refinement stage are probably editorial mistakes. Issue 1. As for white-space-collapse, the glyph areas are deleted, and glyph merging is not applicable. Issue 2. Here is a difference between FO 1.0 and 1.1. In 1.0 the flow objects were deleted at the refinement stage. Therefore they cannot contribute to line breaking. In 1.1 the glyph areas are deleted at the line building stage. Therefore they could contribute to line breaking. I do not think that this is intended, and they should not contribute to line breaking. This is in line with my opinion that the values preserve and ignore should not really be in the same property as suppression around linebreaks, and should be taken care of in the refinement stage. Example 2 ========= The space in "<fo:block>.<fo:block>" is suppressed because it is at the start of the block. And "<fo:block><fo:block>" does not generate an empty line. <fo:block> starts a new line, but that is not equivalent to a linefeed. When at the start of the nested fo:block there is no content in the line yet, it starts the same line. A similar thing happens in the case of "</fo:block>
</fo:block>", which was discussed in an email thread. Example 3 ========= Jörg asked the same in this email thread: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=561781, entitled "Suppression of leading space". <fo:block background-color="red" font-site="20pt"> <fo:inline background-color="blue" font-site="10pt">foo </fo:inline><fo:inline background-color="green" font-site="15pt"> bar</fo:inline></fo:block> <fo:block background-color="red" font-site="20pt">. ..<fo:inline background-color="blue" font-site="10pt">foo. ..</fo:inline><fo:inline background-color="green". ...font-site="15pt">.bar</fo:inline></fo:block> <fo:block background-color="red" font-site="20pt">. <fo:inline background-color="blue" font-site="10pt">foo. </fo:inline><fo:inline background-color="green" font-site="15pt">.bar</fo:inline></fo:block> and also believes that two spaces remain. As to the border of the inline on the next line, I think indeed that a formatter should avoid it, as it may be considered as a bad layout choice. Processing Model 2 ================== In steps 2 and 3 you apply the conditions of glyph area merging. I do not agree with that, as I explained above. In step 3 eligible characters are all characters with suppress-at-line-break="true", by default only the space character. Nowhere in the spec is a conversion of tabs and CRs to spaces specified. In example 3, why is the space before 'Green' not deleted? It directly follows a line break (step 4b). Regards, Simon On Tue, Oct 25, 2005 at 04:57:41PM +0800, Manuel Mall wrote: > Hi, > > I haven't got any technical comments to the issues raised on the Wiki > page. Is this 'too hard' or 'too boring' or 'too messy' or what? The > problem is not going away. We currently don't do it right in some parts > (that is established) but I don't know overall what is right or wrong. > May be if I ask for comments on an issue by issue basis we get > somewhere? > -- Simon Pepping home page: http://www.leverkruid.nl
