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