RE: two more class renamings
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > Sorry to be such a nitpick, but the 1.0 Rec. states > literally: > > "An fo:marker is only permitted as the descendant of > an fo:flow." > and > "An fo:retrieve-marker is only permitted as the > descendant of an > fo:static-content." > Thanks for the correction--I had checked just the content model of fo:flow, which indicated fo:retrieve-marker would be allowed. It would be nice if those two statements above were duplicated in the parent's CM descriptions--that's where people normally go to see which child FO's are allowed/disallowed. Perhaps I'll make a request to the xsl editors ML sometime. Glen
RE: two more class renamings
> -Original Message- > From: Griffin,Sean [mailto:[EMAIL PROTECTED] > > > -Original Message- > > From: Glen Mazza [mailto:[EMAIL PROTECTED] > Sent: Wednesday, > April 06, 2005 9:59 AM > > > 1. fo:static-content is to be repeated from its start on > > every page, and truncated if it doesn't fit. > > You state this very simply and clearly here, but it has always struck me > curiously. There appears to be a gaping hole in the specification that > does not satisfy the need to have content repeat on every page that does > *not* truncate when it does not fit. The "extent" attribute on all > regions that surround the page explicitly defines the size, but I've > found it interesting that there was not an option to have an "auto" > setting that would resize the region to fit the content. Indeed. The most you can do is allow the static-content to overflow the extent of the region. The Rec. also mentions certain user-agents could provide a scrolling mechanism to deal with overflow. > I first thought that this was a 1.0 thing and that in the next version > it would be addressed, but this comment you made that explicitly says > the desired behavior of static-content is to truncate when it does not > fit and that there are no plans to address it. Do you or anyone else on > the developer list know of a compelling reason why this is the case? Compelling? Well, I can see possible difficulties if such functionality were to be provided for all the regions. Consider a simple scenario where an fo:static-content's height depends on the height of a retrieved marker, and would influence the extent of the fo:region-before. This could in its turn have an impact on the extent of the fo:region-body, and that could ultimately lead to the initially retrieved marker shifting to the next page, etc. Cheers, Andreas
RE: two more class renamings
> -Original Message- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 06, 2005 9:59 AM > > 1. fo:static-content is to be repeated from its start on > every page, and truncated if it doesn't fit. You state this very simply and clearly here, but it has always struck me curiously. There appears to be a gaping hole in the specification that does not satisfy the need to have content repeat on every page that does *not* truncate when it does not fit. The "extent" attribute on all regions that surround the page explicitly defines the size, but I've found it interesting that there was not an option to have an "auto" setting that would resize the region to fit the content. I first thought that this was a 1.0 thing and that in the next version it would be addressed, but this comment you made that explicitly says the desired behavior of static-content is to truncate when it does not fit and that there are no plans to address it. Do you or anyone else on the developer list know of a compelling reason why this is the case? CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. --
RE: two more class renamings
> -Original Message- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > > Just one comment: > > --- "Andreas L. Delmelle" <[EMAIL PROTECTED]> > wrote: > > > > After all, there is a key difference > > between Flow and StaticContent when considering > > markers: the first one can contain > > fo:markers, while the second one can only retrieve > > them... > > > > Actually both can have fo:retrieve-marker. Sorry to be such a nitpick, but the 1.0 Rec. states literally: "An fo:marker is only permitted as the descendant of an fo:flow." and "An fo:retrieve-marker is only permitted as the descendant of an fo:static-content." http://www.w3.org/TR/xsl/slice6.html#fo_marker http://www.w3.org/TR/xsl/slice6.html#fo_retrieve-marker -> see Constraints Has this changed in the 1.1 WD? Cheers, Andreas
Re: two more class renamings
Oops, make that three differences: their content models (child FO's that the spec says they can have) are slightly different. Glen --- Glen Mazza <[EMAIL PROTECTED]> wrote: > --- The Web Maestro <[EMAIL PROTECTED]> > wrote: > > > > or something. That way, it's all in one (since it > > can apparently be > > repurposed anyway, with fo:flow being stuck into > > fo:static-content, and > > Be careful here: fo:flow being placed into a "side > region", or fo:static-content being placed into the > "body region" (or main reference area). We really > need to start divorcing the > fo:static-content/fo:flow > terms from where they are usually placed on the > paper. > > The two differences between fo:flow and > fo:static-content are: > > 1. fo:static-content is to be repeated from its > start > on every page, and truncated if it doesn't fit. > > 2. fo:flow is not repeated, but additional pages > created until it its contents are finished. > > Regions of that these FO's are placed on are really > not part of the equation. > > Glen > >
Re: two more class renamings
--- The Web Maestro <[EMAIL PROTECTED]> wrote: > > or something. That way, it's all in one (since it > can apparently be > repurposed anyway, with fo:flow being stuck into > fo:static-content, and Be careful here: fo:flow being placed into a "side region", or fo:static-content being placed into the "body region" (or main reference area). We really need to start divorcing the fo:static-content/fo:flow terms from where they are usually placed on the paper. The two differences between fo:flow and fo:static-content are: 1. fo:static-content is to be repeated from its start on every page, and truncated if it doesn't fit. 2. fo:flow is not repeated, but additional pages created until it its contents are finished. Regions of that these FO's are placed on are really not part of the equation. Glen
Re: two more class renamings
On Apr 5, 2005, at 6:20 PM, Glen Mazza wrote:
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote:
Except for ... (see above)? Hmm... Why would we even
*need* *two* *different* LMs?
Don't get me wrong: I'm *not* encouraging you to
merge the two classes completely ;-P
Still can't put my finger on it, but something seems
not quite OK with having two separate LM classes that 'do the same
thing, regardless of the input coming from an fo:flow or an
fo:static-content'
No, no, no...
BodyRegionLM will handle fo:flow and fo:static-content
equivalently.
SideRegionLM will handle fo:flow and fo:static-content
equivalently.
BodyRegionLM and SideRegionLM would handle these
objects very differently.
Forgive my naiveté, but why not just have something like:
LayoutManager(), and inside that determine whether it's body, side or
flow, or whatever?
I'm thinking something along the lines of:
LayoutManager('region-body',...)
LayoutManager('region-start',...)
LayoutManager('region-end',...)
or something. That way, it's all in one (since it can apparently be
repurposed anyway, with fo:flow being stuck into fo:static-content, and
vice versa).
Just a thought...
Web Maestro Clay
--
<[EMAIL PROTECTED]> -
RE: two more class renamings
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > > > SideRegionLM handles the layout of input into a > r-r-area > > that does not have spans [...] does the same thing > > regardless of the input coming from an fo:flow or > an > > fo:static-content. > > > > NormalFlowLM handles the layout of input into > > multi-column/multi-span areas [...] does the same > thing > > regardless of the input coming from an fo:flow or > an > > fo:static-content. > > Except for ... (see above)? Hmm... Why would we even > *need* *two* > *different* LMs? > Don't get me wrong: I'm *not* encouraging you to > merge the two classes > completely ;-P > > Still can't put my finger on it, but something seems > not quite OK with > having two separate LM classes that 'do the same > thing, regardless of the > input coming from an fo:flow or an > fo:static-content' No, no, no... BodyRegionLM will handle fo:flow and fo:static-content equivalently. SideRegionLM will handle fo:flow and fo:static-content equivalently. BodyRegionLM and SideRegionLM would handle these objects very differently. > solely on the basis > that they layout different page regions, with or > without columns/spans...? > I hate to be the show-stopper, but I still need to > be convinced that there > is not actually a better way to go about this :-/ I'm going to withdraw my suggestion anyway. I have a lot more studying to do on this before continuing. I am clearly not on solid enough ground for this. If FlowLayoutManager is currently responsible for the layout of an entire fo:flow object, no matter what region it is placed on and no matter how many pages are needed, I completely agree it should be called FlowLayoutManager. But if this class is just to layout a single BodyRegion of a page, and multiple instances of it are activated by PSLM while it is processing its own fo:flow object, then it should be called BodyRegionLM. Studying the current logic in PSLM and FLM, it appears to be half-and-half. A single FlowLayoutManager instance is indeed in memory for the entire fo:flow, but PSLM is doing the job of parsing out the fo:flow on to multiple pages, and also apparently even collecting the areas that make up the fo:flow. So FlowLayoutManager and StaticContentLayoutManager it will remain under the current logic. I'm dropping my suggestion--I clearly have a lot more studying to do on this. Thanks, Glen
RE: two more class renamings
Andreas, thanks for your well-thought out response here. I appreciate the effort, and sorry for not responding earlier. Just one comment: --- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > After all, there is a key difference > between Flow and > StaticContent when considering markers: the first > one can contain > fo:markers, while the second one can only retrieve > them... > Actually both can have fo:retrieve-marker. But our input validation system prevents fo:static-content from having marker children, so probably no harm done when you get to layout--any code that attempted to extract the fo:marker children from an fo:static-content would get an empty list. Glen
RE: two more class renamings
> -Original Message- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > > --- Simon Pepping <[EMAIL PROTECTED]> wrote: > > > > What Andreas argues here is what I would think as > > well: The LMs are tied to the formatting objects, > > not to the page regions they populate. > > I don't see it that way, because both an fo:flow and > an fo:static-content are handled equivalently when > sent to a SideRegion, and both are handled > equivalently when sent to the BodyRegion. Apart from markers, which will always be handled differently for Flow and StaticContent, whether sent to the BodyRegion or a SideRegion... > > SideRegionLM handles the layout of input into a r-r-area > that does not have spans [...] does the same thing > regardless of the input coming from an fo:flow or an > fo:static-content. > > NormalFlowLM handles the layout of input into > multi-column/multi-span areas [...] does the same thing > regardless of the input coming from an fo:flow or an > fo:static-content. Except for ... (see above)? Hmm... Why would we even *need* *two* *different* LMs? Don't get me wrong: I'm *not* encouraging you to merge the two classes completely ;-P Still can't put my finger on it, but something seems not quite OK with having two separate LM classes that 'do the same thing, regardless of the input coming from an fo:flow or an fo:static-content' --solely on the basis that they layout different page regions, with or without columns/spans...? I hate to be the show-stopper, but I still need to be convinced that there is not actually a better way to go about this :-/ If one were to say, for instance, instead of renaming these two classes, just add a third one --call it RegionBodyLM, SpanLM or whatever-- containing the logic to deal with multi-column/multi-span, and have this latter one do its work in close co-operation with the other two and the PSLM... Now, that would be a different story. I can't really explain it, but will try... It just seems that, in a few weeks/months we're bound to find out the hard way that simply renaming two classes to make them conceptually fit into a processing-flow that doesn't yet exist, will make the implementation of precisely that processing-flow all the more difficult. Somehow it looks like we're going to need that extra class anyway. If that turns out to be true, I'd rather see it added now, and base it upon the line of thought that: 1) one or more FlowLMs manage layout for an fo:flow 2) one or more SCLMs do the same for the fo:static-contents 3) the PSLM controls both, plus... 4) the SpanLM(?) that takes care of the possible multi-column/-span layout, in combination with 1) or 2) The side-regions, IIC, can ATM be handled by the PSLM in conjunction with FlowLM or SCLM directly --and the intervention of 4) should *depend* upon multi-column/-span properties being used. If they aren't, the current setup should work nicely, without any classes being renamed, just a null reference added. Long shot... maybe in some future versions of the Rec., the possibility of multi-column layout will be introduced for the side-regions --why not? (And if so, your current proposal would turn out to have had ... which benefit exactly? --No offence intended, just trying to build my case here, for I see faint images of two separate classes containing lots of duplicate code...) Cheers, Andreas
Re: two more class renamings
--- Simon Pepping <[EMAIL PROTECTED]> wrote: > > What Andreas argues here is what I would think as > well: The LMs are > tied to the formatting objects, not to the page > regions they populate. > > Regards, Simon > I don't see it that way, because both an fo:flow and an fo:static-content are handled equivalently when sent to a SideRegion, and both are handled equivalently when sent to the BodyRegion. SideRegionLM handles the layout of input into a region-reference-area that does not have spans (and therefore columns/normal-flow-reference-areas, column-balancing, etc.) It does the same thing regardless of the input coming from an fo:flow or an fo:static-content. NormalFlowLM handles the layout of input into multi-column/multi-span areas of a region-body. It does the same thing regardless of the input coming from an fo:flow or an fo:static-content. [I am unsure, however, whether NormalFlowLM is to handle just one normal flow (column), all the normal-flows of the span, or all the spans of the body-region, it may turn out that renaming it SpanLM or RegionBodyLM may make more sense. Now that I think about it, RegionBodyLM ATM probably makes the most amount of sense.] The routing that Andreas mentions is already handled by PSLM, which also makes sure that additional pages are created to satisfy fo:flows, and that fo:static-contents are duplicated on each page. This routing is really the flow-map (implicit in 1.0, explicit in 1.1) which is the directing of flows (fo:static-content or fo:flow) on one side to (multiple) regions (SideRegionLM and/or RegionBodyLM, as appropriate) on the other. Glen
Re: two more class renamings
What Andreas argues here is what I would think as well: The LMs are tied to the formatting objects, not to the page regions they populate. Regards, Simon On Tue, Apr 05, 2005 at 07:10:40PM +0200, Andreas L. Delmelle wrote: > > -Original Message- > > From: Glen Mazza [mailto:[EMAIL PROTECTED] > > > > Hi, > > > I see two LM classes that appear misnamed, which can > > cause confusion as to their purpose: > > > > 1.) FlowLayoutManager is defined as "the layout > > manager for an fo:flow object" -- but actually it can > > also be for an fo:static-content object if the static > > content is directed to the region-body of the page. > > So, IIC you're considering the FlowLM or StaticContentLM as being unrelated > to the fo:flow or fo:static-content objects --or at least: more related to > the page-regions than to the formatting objects? > > Agreed that, according to the XSL Spec. --WD or not--, it's allowed to > redirect the fo:static-content (for example) to a different region than > 'before' or 'after', but it could be argued that another option is to let > the StaticContentLM take care of the redirection of the fo:static-content to > the right region... I suppose the current StaticContentLM should already > allow for redirection to either 'xsl-region-before' or 'xsl-region-after', > so it should be quite straightforward to add 'xsl-region-body' as another > alternative (?) After all, there is a key difference between Flow and > StaticContent when considering markers: the first one can contain > fo:markers, while the second one can only retrieve them... > One aspect that *does* seem to become increasingly important is the > inter-play of the StaticContentLM and the FlowLM --if both can layout to the > same region(s). > > IMO there is no solid argument against the *reason* itself for this > renaming --on the contrary, it seems more than reasonable--, but regardless > of its validity, I do have my doubts on the end-result of the proposed way > to solve the related issues... > > > Cheers, > > Andreas > -- Simon Pepping home page: http://www.leverkruid.nl
RE: two more class renamings
> -Original Message- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > Hi, > I see two LM classes that appear misnamed, which can > cause confusion as to their purpose: > > 1.) FlowLayoutManager is defined as "the layout > manager for an fo:flow object" -- but actually it can > also be for an fo:static-content object if the static > content is directed to the region-body of the page. So, IIC you're considering the FlowLM or StaticContentLM as being unrelated to the fo:flow or fo:static-content objects --or at least: more related to the page-regions than to the formatting objects? Agreed that, according to the XSL Spec. --WD or not--, it's allowed to redirect the fo:static-content (for example) to a different region than 'before' or 'after', but it could be argued that another option is to let the StaticContentLM take care of the redirection of the fo:static-content to the right region... I suppose the current StaticContentLM should already allow for redirection to either 'xsl-region-before' or 'xsl-region-after', so it should be quite straightforward to add 'xsl-region-body' as another alternative (?) After all, there is a key difference between Flow and StaticContent when considering markers: the first one can contain fo:markers, while the second one can only retrieve them... One aspect that *does* seem to become increasingly important is the inter-play of the StaticContentLM and the FlowLM --if both can layout to the same region(s). IMO there is no solid argument against the *reason* itself for this renaming --on the contrary, it seems more than reasonable--, but regardless of its validity, I do have my doubts on the end-result of the proposed way to solve the related issues... Cheers, Andreas
Re: two more class renamings
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > Glen Mazza wrote: > > if the static > > content is directed to the region-body of the > page. > > Is this even allowed by the spec? Actually yes! AFAICT you are welcome to set the flow name on fo:static-content[1] to "xsl-region-body" or any of the other region classes[2]. Nothing in the spec prohibits it, indeed with upcoming 1.1 xsl:flow-map, it will even be easier to route to *multiple* regions. [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#flow-name [2] http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#region-name (Note the latter two region-classes --xsl-before-float-separator and xsl-footnote-separator--in [2] are actually just flow-names, not region-names, I informed the W3C and they removed those two from the region-name listing for 1.1.) > > > 2.) Similarly, the StaticContentLayoutManager > should > > be renamed to SideRegionLayoutManager, because the > > output of both fo:static-content and fo:flow can > be > > directed to it, > > No, the latter can't happen. The 0.20.5 branch even > tests > for this and aborts in that case. > Yes, that check is in PSLM, but I changed the text to say that FOP *currently* doesn't support that. Everything I'm seeing in 1.0 (flow-name and region-name properties) and 1.1 (same plus fo:flow-map) says it is perfectly kosher to redirect fo:flow to a side-region(1.1: side-region*s*), and fo:static-content to a fo:region-body. That's why these classes are really NormalFlowLayoutManager and SideRegionLayoutManager--this distinction will especially important in 1.1, where fo:flow-map lets you route everything everywhere. Glen
Re: two more class renamings
J.Pietschmann wrote: Glen Mazza wrote: if the static content is directed to the region-body of the page. Is this even allowed by the spec? No, this isnt valid. 2.) Similarly, the StaticContentLayoutManager should be renamed to SideRegionLayoutManager, because the output of both fo:static-content and fo:flow can be directed to it, No, the latter can't happen. The 0.20.5 branch even tests for this and aborts in that case. Glen: I dont think its appropriate to rename these classes as your reasoning appears flawed. Chris
Re: two more class renamings
Glen Mazza wrote: if the static content is directed to the region-body of the page. Is this even allowed by the spec? 2.) Similarly, the StaticContentLayoutManager should be renamed to SideRegionLayoutManager, because the output of both fo:static-content and fo:flow can be directed to it, No, the latter can't happen. The 0.20.5 branch even tests for this and aborts in that case. J.Pietschmann
two more class renamings
Team, I see two LM classes that appear misnamed, which can cause confusion as to their purpose: 1.) FlowLayoutManager is defined as "the layout manager for an fo:flow object" -- but actually it can also be for an fo:static-content object if the static content is directed to the region-body of the page. Further, the class processes a single normal-flow-reference-area (i.e., a column) within a span-reference-area of the region-body of the page[1]. In other words, the processing of an fo:flow actually could take *several* of these objects if the span is multi-column, or its output takes several pages. So I think FlowLayoutManager should be renamed to NormalFlowLayoutManager. 2.) Similarly, the StaticContentLayoutManager should be renamed to SideRegionLayoutManager, because the output of both fo:static-content and fo:flow can be directed to it, also fo:static-content can actually end up being rendered by NormalFlowLayoutManager(s) if (1) above occurs. Any objection to the two renamings? Thanks, Glen [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_region-body
