Negative values for margin-top and space-before attributes of fo:block have no effect on the position of text as rendered in PDF format. FOP seems to ignore negative values for these attributes. I assume the other margin-bottom, right left, etc. are effected as well. This was tested using FOP 0.91 I tried to find out if the XSL-FO specs allow negative values here, but I didn't discover an answer. Negative values work in XEP, however, and are pretty darn useful. I tried to work around this by moving the fo:block with the top coordinate property, but that didn't work with FOP or XEP.
Would you please attach an example that shows the effect that you describe? My suspicion is that you don't take space conditionality into account. Please note that the .conditionality part of space-before/space-after defaults to discard. And if a space-before occurs at the beginning of a document (i.e. starting a reference area) it may be discarded if it is conditional. AFAIK, XEP may have some issues here. For more details, please see the XSL-FO specification at http://www.w3.org/TR/xsl/slice4.html#area-space. margin-top is a different beast. It is mapped to space-before and the .conditionality component is set to retain (5.3.2 in the spec) so it shouldn't be discarded. On the other side, we do have tests that verify that negative values are properly handled. A short test shows me that everything is working as expected. So please do provide a test file.
Created attachment 17355 [details] demonstrates how negative space-before values are ignored This test case shows two problems: 1) negative space-before values are ignored when the preceding block has span=all in a 2 column region. 2) negative space-before values work without span=all on the block before, but then there are some quirks with how the text is printed in the PDF (see XML comments)
Matt, I've had a look at your test case. I must say that I can't determine with 100% confidence what you're trying to show. I've found one problem with your test case: Running your test case unmodified causes the span="all" block to be ignored. The problem here is that the negative space-before is larger than the positive height by the height of the single line of text and the space-after added together (-18pt + 12pt + 2.5pt = -3.5pt). There is some code in the area tree that causes a span area with a negative height to be removed. This seems wrong. I'm going to change that. As for the other cases you describe, I can't reproduce them. A negative space-before with conditionality="retain" on a block after a block with span="all" works just fine (your point 1). On your point 2, I can only say that your test case is a little weird, since the lines "HeaderText1" etc. have a huge start-indent. Your text in the first block is indeed balanced to two columns (which is correct). HeaderText lines 3 to 6 are not visible as they have a start-indent that places them outside the main reference area (even outside the page) for the second column. I'd like to suggest you revise your test case again, maybe try to simplify it. What's often helpful to determine problems is using background-color on region-body and blocks to see which area is taken up exactly by the various elements. Also, set overflow to "visible" while looking for problems. As an advanced means you can have a look at the output of the area tree XML output (-at on the command-line). It can give you an indicator whether some parts have been ignored/discarded or if they are painted but offset so they are not visible.
The problem with spans of negative height being swallowed is fixed now: http://svn.apache.org/viewcvs?rev=367262&view=rev
Created attachment 17494 [details] this case shows how space-before is ignored if the previous block has a space-after attribute Please ignore my previous comments and take a look at the behavior here. I realized that my fo:block was ignoring its space-before attribute because its previous sibling had a space-after property larger than 0in. But I don't think the output makes sense.
Additional info concerning the second attachment: The native XSL-FO space-* properties support a .precedence component. If you make it: <fo:block space-after=".1in" space-after.precedence="0" background-color="red"> Red block </fo:block> <fo:block space-before="-.1in" space-before.precedence="1" background-color="blue"> Blue block </fo:block> then FOP Trunk renders it as intended. If no .precedence is specified, then they both revert to zero, and the 'largest' space wins. Also, margin-top seems to correctly lead to a retained space, so I consider this to be fixed.
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed