DO NOT REPLY [Bug 47380] New: Alignment handling text-align-last="justify"

https://issues.apache.org/bugzilla/show_bug.cgi?id=47380

           Summary: Alignment handling text-align-last="justify"
           Product: Fop
           Version: 1.0dev
          Platform: PC
        OS/Version: Windows Server 2003
            Status: NEW
          Severity: regression
          Priority: P2
         Component: general
        AssignedTo: fop-dev@...
        ReportedBy: gd@...


<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

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47380





--- Comment #1 from Andreas L. Delmelle <adelmelle@...>  2009-06-17 04:31:25 PST ---

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...

--- Comment #2 from Andreas L. Delmelle <adelmelle@...>  2009-06-17 04:31:25 PST ---

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...

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47380





--- Comment #1 from Andreas L. Delmelle <adelmelle@...>  2009-06-17 04:31:25 PST ---

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...

--- Comment #2 from Andreas L. Delmelle <adelmelle@...>  2009-06-17 04:31:25 PST ---

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...

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://issues.apache.org/bugzilla/show_bug.cgi?id=47380





--- Comment #3 from Andreas L. Delmelle <adelmelle@...>  2009-06-17 05:42:49 PST ---
(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 (?)

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.