Re: overlapping regions
Glen Mazza wrote: When I have overlapping regions (e.g., fo:region-start/after/before/end are defined but no margins are provided within fo:region-body to accomodate their extents--see example below), the spec doesn't appear to indicate which region should win. ... Judging from background-color, the maintenance version lets all side regions win A side effect of doing layout of the static content after laying out the flow. (not necessarily the correct answer), Well, the spec is remarkably unhelpful for determining what the correct answer should be. However, the layout of the non-body region issomewhat better defined and the obvious overlapping effects can be controlled by the precedence property. Unless these regions overlap as well, there are two consistent behaviours: 1. the body content is consistently drawn on top of the other regions 2. the other regions are consistently drawn over the body. Both have their use cases. while trunk lets only fo:region-after and -end win. (See attachments.) Does this matter? It looks ugly. I'd suggest to restore the behaviour of the maintenance code I expected this to be implemented this way anyway, because last time I looked regions were handled the same order as in the maintenance code). Vic, could this be an artefact of your changes? In the long run, some FOP extensions to control stacking order could be explored. J.Pietschmann
RE: overlapping regions
J.Pietschmann wrote: I'd suggest to restore the behaviour of the maintenance code I expected this to be implemented this way anyway, because last time I looked regions were handled the same order as in the maintenance code). Vic, could this be an artefact of your changes? It is certainly possible. Glen, if this is not easy to fix according to Joerg's comments, then I'll be glad to check out a snapshot from 3-4 weeks ago, and compare the behavior to what we have now to see if I caused this. Victor Mote
RE: overlapping regions
Don't bother--issue is not that important. I guess our general goal is to do what maintenance does for overlapping regions (which the spec doesn't address anyway but maintenance seems to handle nicely)--I may take a look at it later. Glen --- Victor Mote [EMAIL PROTECTED] wrote: J.Pietschmann wrote: I'd suggest to restore the behaviour of the maintenance code I expected this to be implemented this way anyway, because last time I looked regions were handled the same order as in the maintenance code). Vic, could this be an artefact of your changes? It is certainly possible. Glen, if this is not easy to fix according to Joerg's comments, then I'll be glad to check out a snapshot from 3-4 weeks ago, and compare the behavior to what we have now to see if I caused this. Victor Mote __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
overlapping regions
Question, When I have overlapping regions (e.g., fo:region-start/after/before/end are defined but no margins are provided within fo:region-body to accomodate their extents--see example below), the spec doesn't appear to indicate which region should win. What it does say (6.4.13) at least is this: The spacing between the last four regions [those listed above] and the fo:region-body is determined by subtracting the relevant extent trait on the side regions from the trait that corresponds to the margin-x property on the fo:region-body. Judging from background-color, the maintenance version lets all side regions win (not necessarily the correct answer), while trunk lets only fo:region-after and -end win. (See attachments.) Does this matter? In the case where no margins were defined within fo:region-body, can/should we indeed let the results be undefined? Thanks, Glen ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=letter page-height=11in page-width=8.5in margin-top=1in margin-bottom=1in margin-left=1in margin-right=1in fo:region-before extent=1cm background-color=yellow/ fo:region-start extent=1cm background-color=purple / fo:region-body background-color=green/ fo:region-endextent=1cm background-color=orange/ fo:region-after extent=1cm background-color=blue / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=letter fo:flow flow-name=xsl-region-body fo:blockHello World!/fo:block /fo:flow /fo:page-sequence /fo:root __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com helloworldMaint.pdf Description: helloworldMaint.pdf helloworldTrunk.pdf Description: helloworldTrunk.pdf
DO NOT REPLY [Bug 8815] - Irritating overlapping regions in examples
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8815. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8815 Irritating overlapping regions in examples [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-30 00:30 --- Fixed in cvs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8815] New: - Irritating overlapping regions in examples
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8815. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8815 Irritating overlapping regions in examples Summary: Irritating overlapping regions in examples Product: Fop Version: 0.20.3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Many of the examples distributed with FOP define a region-after but don't set corresponding margin-bottom, thereby creating overlapping regions. This could irritate users. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
