|

»

w3.org - xsl-editors

[Bug 6276] New: Breaks and Borders, Successive Break Contexts

View: New views

5 Messages — Rating Filter: Alert me

	[Bug 6276] New: Breaks and Borders, Successive Break Contexts by Bugzilla from bugzilla@wiggum.w3.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message http://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 Summary: Breaks and Borders, Successive Break Contexts Product: XSLFO Version: 1.1 Platform: All URL: http://lists.w3.org/Archives/Public/xsl- editors/2008AprJun/0003 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XSL-FO AssignedTo: alb.w3c@... ReportedBy: Tony.Graham@... QAContact: xsl-editors@... >From xsl-editors: The following situations are not explicitly described by the XSL-FO 1.1 Recommendation and no consistent behaviour could be found among the various implementations: Given the following FO snippet: <fo:block border-before-color="black" border-before-style="double" border-before-width="1pt"> <fo:block break-before="page"> Some text. </fo:block> </fo:block> If the outer block is not leading in the page-reference-area (does not start a page), what is the expected rendering? Should the border-before lie on page n and the inner block on page n+1: ______________ ______________ \| \| \| \| \| ... \| \| Some text. \| \| Content \| \| \| \| before \| \| \| \| ... \| \| \| \| \| \| \| \| ========== \| \| \| \| \| \| \| \|____________\| \|____________\| ... or should both be found on page n+1? ______________ ______________ \| \| \| \| \| ... \| \| ========== \| \| Content \| \| Some text. \| \| before \| \| \| \| ... \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|____________\| \|____________\| In other words: if the first child of an fo:block has a forced (page) break, should this block still produce an empty area (that here will hold a before border) on the current page, or should it be deferred to the next page along with its childs area(s)? As another illustration of this issue, in the following case, and assuming that we have a two-column page setup: <fo:block break-before="column" border-top="1pt solid red"> <fo:block break-before="page" border-top="1pt solid blue"> Some text. </fo:block> </fo:block> Lets assume that when the outer block is reached we are inside the first column of page n. Should (1) the red border be found at the top of column #2 on page n, and the blue border at the top of column #1 on page n+1? Or should (2) both borders be found at the top of column #1 on page n+1? If empty areas must be produced, then case (1) would win; otherwise this would be case (2). On a slightly different topic, there is a small uncertainty in cases like the following: <fo:block break-before="page"> <fo:block break-before="page"> Some text. </fo:block> </fo:block> Should an empty page be generated? In which case the outer block would generate an empty area on page n+1, and the inner block its area(s) on page n+2. If not, then both blocks would generate their areas on page n+1. Both behaviours are compliant with the Recommendation I think. But within the FOP team we couldnt reach a consensus on which one should be privileged. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
	[Bug 6276] Breaks and Borders, Successive Break Contexts by Bugzilla from bugzilla@wiggum.w3.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message http://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 --- Comment #1 from Tony Graham <Tony.Graham@...> 2008-12-18 12:24:25 --- The FO subgroup has considered your three cases: 1. There is nothing in the XSL 1.1 Recommendation that has an fo:block generating an empty area before jumping to the next page. So the border-before follows the rest of the block to the next page. 2. For the same reason, both borders should go on column 1 of page n+1. 3. For the same reason: no, there should not be an empty page. In accordance with the instructions at http://www.w3.org/XML/2008/01/xsl-fo-bugzilla.html#verify, please review the proposed resolution carefully and let the Working Group know whether it's acceptable or not. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
	[Bug 6276] Breaks and Borders, Successive Break Contexts by Bugzilla from bugzilla@wiggum.w3.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message http://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 Tony Graham <Tony.Graham@...> changed: What \|Removed \|Added ---------------------------------------------------------------------------- CC\| \|vhennebert@... --- Comment #2 from Tony Graham <Tony.Graham@...> 2009-01-13 12:44:21 --- Adding original poster as CC. Response from original poster required to resolve bug report. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
	[Bug 6276] Breaks and Borders, Successive Break Contexts by Bugzilla from bugzilla@wiggum.w3.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message http://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 --- Comment #3 from Vincent Hennebert <vhennebert@...> 2009-03-02 11:07:45 --- Thanks for the clarification. I believe it clears the uncertainties that were still existing in that area. The bug can be closed now. Vincent Hennebert -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
	[Bug 6276] Breaks and Borders, Successive Break Contexts by Bugzilla from bugzilla@wiggum.w3.org :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message http://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 Tony Graham <Tony.Graham@...> changed: What \|Removed \|Added ---------------------------------------------------------------------------- Status\|NEW \|RESOLVED Resolution\| \|INVALID --- Comment #4 from Tony Graham <Tony.Graham@...> 2009-03-03 09:23:48 --- (In reply to comment #3) > Thanks for the clarification. I believe it clears the uncertainties that were > still existing in that area. The bug can be closed now. Closing as "invalid" since that's the best we can do with this Bugzilla to close an issue that does not indicate a problem with the spec. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.