Bug 47380 - specified rule-thickness applies only when leader-pattern is rule, otherwise should use default thickness
Summary: specified rule-thickness applies only when leader-pattern is rule, otherwise ...
Status: RESOLVED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: trunk
Hardware: PC Windows Server 2003
: P3 regression
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-17 03:39 UTC by Georg Datterl
Modified: 2012-04-07 09:25 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Georg Datterl 2009-06-17 03:39:37 UTC
<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
Comment 1 Andreas L. Delmelle 2009-06-17 04:31:25 UTC
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 Andreas L. Delmelle 2009-06-17 04:31:25 UTC
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 3 Andreas L. Delmelle 2009-06-17 05:42:49 UTC
(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 (?)
Comment 4 Glenn Adams 2012-04-07 01:43:40 UTC
resetting P2 open bugs to P3 pending further review
Comment 5 Glenn Adams 2012-04-07 07:46:16 UTC
(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.