FOP
  1. FOP
  2. FOP-1676

specified rule-thickness applies only when leader-pattern is rule, otherwise should use default thickness

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: unqualified
    • Labels:
      None
    • Environment:
      Operating System: Windows Server 2003
      Platform: PC
    • External issue ID:
      47380

      Description

      <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:fox="http://xmlgraphics.apache.org/fop/extensions">
      <fo:layout-master-set>
      <fo:simple-page-master page-height="10cm" page-width="15cm" master-name="main">
      <fo:region-body/>
      </fo:simple-page-master>
      </fo:layout-master-set>
      <fo:page-sequence master-reference="main">
      <fo:flow flow-name="xsl-region-body">
      <fo:block text-align-last="justify" span="all" width="15cm">
      <fo:inline background-color="red">left page border</fo:inline>
      <fo:leader leader-pattern="space" rule-style="dotted" rule-thickness="0.0pt" background-color="yellow"/>
      <fo:inline text-align="right" background-color="green">right page border?</fo:inline>
      </fo:block>
      </fo:flow>
      </fo:page-sequence>
      </fo:root>

      One block, an inline left, an inline right, a leader in between. I'd expect the right inline to end at the right page end.

      Not working in Version 784924
      Still working in a build made on 2009/05/19, definitely before IF was included in trunk (which does not mean, IF is responsible for the error!)

      Manifest snippet:

      Build-Id: 20090519-142808-CEST (gdatterl [Windows 2003 5.2 amd64, Java
      1.5.0_15-b04])
      Class-Path: PDFBox-0.7.4-dev.jar avalon-framework-4.2.0.jar batik-all-
      1.7.jar checkstyle-all-5.0-beta01.jar commons-io-1.3.1.jar commons-lo
      gging-1.0.4.jar fop-pdf-images-1.3.jar jai_codec.jar jai_core.jar jun
      it-4.5.jar serializer-2.7.0.jar servlet-2.2.jar xalan-2.7.0.jar xerce
      sImpl-2.7.1.jar xml-apis-1.3.04.jar xml-apis-ext-1.3.04.jar xmlgraphi
      cs-commons-1.4svn.jar xmlunit-1.2.jar

        Activity

        Show
        Glenn Adams added a comment - http://svn.apache.org/viewvc?view=revision&revision=1310717
        Hide
        Glenn Adams added a comment -

        (In reply to comment #0)
        > One block, an inline left, an inline right, a leader in between. I'd expect the
        > right inline to end at the right page end.

        Saying "inline left" and "inline right" and specifying text-align="right" on the second inline is misleading since text-align does not apply to inline, but only to block (and similar).

        If the second inline is aligned right, it would only be due to the text-align-last="justify" specified on the block.

        Show
        Glenn Adams added a comment - (In reply to comment #0) > One block, an inline left, an inline right, a leader in between. I'd expect the > right inline to end at the right page end. Saying "inline left" and "inline right" and specifying text-align="right" on the second inline is misleading since text-align does not apply to inline, but only to block (and similar). If the second inline is aligned right, it would only be due to the text-align-last="justify" specified on the block.
        Hide
        Glenn Adams added a comment -

        resetting P2 open bugs to P3 pending further review

        Show
        Glenn Adams added a comment - resetting P2 open bugs to P3 pending further review
        Hide
        Andreas L. Delmelle added a comment -

        (In reply to comment #2)
        > Also found the revision that (most likely) introduced this:
        > http://svn.apache.org/viewvc?rev=749012&view=rev
        >
        > A zero-width rule-thickness would lead to an area with zero bpd, and such an
        > area is probably skipped during rendering...

        Checking the XSL-FO Rec. closer, part of that commit was definitely a mistake, since rule-thickness is not supposed to have any effect, unless the leader-pattern is specified as "rule".
        Same goes for the rule-style property, so one could even argue that those two properties should not be specified, since the pattern is "space"...
        If you omit rule-thickness, the issue is also worked around, since rule-thickness then defaults to 1.0pt (but then, obviously, the yellow background becomes clearly visible).

        Still a regression, but I'll need some more background info before I'm going to revert the change in question. For leader-pattern='space', I guess we'd better look at the line-height property to determine the b-p-d trait for the corresponding area

        Show
        Andreas L. Delmelle added a comment - (In reply to comment #2) > Also found the revision that (most likely) introduced this: > http://svn.apache.org/viewvc?rev=749012&view=rev > > A zero-width rule-thickness would lead to an area with zero bpd, and such an > area is probably skipped during rendering... Checking the XSL-FO Rec. closer, part of that commit was definitely a mistake, since rule-thickness is not supposed to have any effect, unless the leader-pattern is specified as "rule". Same goes for the rule-style property, so one could even argue that those two properties should not be specified, since the pattern is "space"... If you omit rule-thickness, the issue is also worked around, since rule-thickness then defaults to 1.0pt (but then, obviously, the yellow background becomes clearly visible). Still a regression, but I'll need some more background info before I'm going to revert the change in question. For leader-pattern='space', I guess we'd better look at the line-height property to determine the b-p-d trait for the corresponding area
        Hide
        Andreas L. Delmelle added a comment -

        No precise idea on the exact cause, but I already played with the testcase a bit, and it seems that changing rule-thickness to 0.1pt suffices to achieve the desired result.

        Also found the revision that (most likely) introduced this:
        http://svn.apache.org/viewvc?rev=749012&view=rev

        A zero-width rule-thickness would lead to an area with zero bpd, and such an area is probably skipped during rendering...

        Show
        Andreas L. Delmelle added a comment - No precise idea on the exact cause, but I already played with the testcase a bit, and it seems that changing rule-thickness to 0.1pt suffices to achieve the desired result. Also found the revision that (most likely) introduced this: http://svn.apache.org/viewvc?rev=749012&view=rev A zero-width rule-thickness would lead to an area with zero bpd, and such an area is probably skipped during rendering...
        Hide
        Andreas L. Delmelle added a comment -

        No precise idea on the exact cause, but I already played with the testcase a bit, and it seems that changing rule-thickness to 0.1pt suffices to achieve the desired result.

        Also found the revision that (most likely) introduced this:
        http://svn.apache.org/viewvc?rev=749012&view=rev

        A zero-width rule-thickness would lead to an area with zero bpd, and such an area is probably skipped during rendering...

        Show
        Andreas L. Delmelle added a comment - No precise idea on the exact cause, but I already played with the testcase a bit, and it seems that changing rule-thickness to 0.1pt suffices to achieve the desired result. Also found the revision that (most likely) introduced this: http://svn.apache.org/viewvc?rev=749012&view=rev A zero-width rule-thickness would lead to an area with zero bpd, and such an area is probably skipped during rendering...

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development