Fop
  1. Fop
  2. FOP-1119

Negative values for margin-top and space-before attributes of fo:block are ignored

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 0.91
    • Fix Version/s: None
    • Component/s: pdf
    • Labels:
      None
    • Environment:
      Operating System: Windows XP
      Platform: PC
    • External issue ID:
      38054

      Description

      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.

      1. testcase2.fo
        1 kB
        Matt LeClair
      2. testcase1.fo
        2 kB
        Matt LeClair

        Activity

        Hide
        Glenn Adams added a comment -

        batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

        Show
        Glenn Adams added a comment - batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed
        Hide
        Andreas L. Delmelle added a comment -

        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.

        Show
        Andreas L. Delmelle added a comment - 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.
        Hide
        Matt LeClair added a comment -

        Attachment testcase2.fo has been added with description: this case shows how space-before is ignored if the previous block has a space-after attribute

        Show
        Matt LeClair added a comment - Attachment testcase2.fo has been added with description: this case shows how space-before is ignored if the previous block has a space-after attribute
        Hide
        Matt LeClair added a comment -

        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.

        Show
        Matt LeClair added a comment - 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.
        Hide
        Jeremias Maerki added a comment -

        The problem with spans of negative height being swallowed is fixed now:
        http://svn.apache.org/viewcvs?rev=367262&view=rev

        Show
        Jeremias Maerki added a comment - The problem with spans of negative height being swallowed is fixed now: http://svn.apache.org/viewcvs?rev=367262&view=rev
        Hide
        Jeremias Maerki added a comment -

        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.

        Show
        Jeremias Maerki added a comment - 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.
        Hide
        Matt LeClair added a comment -

        Attachment testcase1.fo has been added with description: demonstrates how negative space-before values are ignored

        Show
        Matt LeClair added a comment - Attachment testcase1.fo has been added with description: demonstrates how negative space-before values are ignored
        Hide
        Matt LeClair added a comment -

        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)

        Show
        Matt LeClair added a comment - 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)
        Hide
        Jeremias Maerki added a comment -

        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.

        Show
        Jeremias Maerki added a comment - 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.

          People

          • Assignee:
            fop-dev
            Reporter:
            Matt LeClair
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development