RE: Problems with break conditions and empty pages

[Andreas L. Delmelle]

> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> --- Luca Furini <[EMAIL PROTECTED]> wrote:
> >
> >
> > My first impression is that I would find somewhat
> > strange that the *page* breaking is not in the
> > *Page*SequenceLM! :-)
> >
>
> Well, under our current philosophy, our LM's map to
> the formatting object (here, the "page sequence"), not
> the areas they generate.  I was reminded a bit on that
> a few weeks ago by Andreas and Simon.
>
> You may recall, I recommended at the time that we have
> BodyRegionLM and a SideRegionLM instead of a FLM and a
> StaticContentLM.  Under this scenario, PSLM controls
> complete page-by-page layout, and delegates to the
> BRLM and SRLM to do the body region or side areas.
>
> But if we have an "FLM" instead, my thinking is that
> it should perhaps process the entire
> fo:flow--including the creation of multiple
> page-viewport-areas in order to consume that flow.
>

Hmm.. This does seem to be one of those situations where the logic could be
placed anywhere. However, taking into account Luca's remarks, I would be
inclined to see it as:

"The PSLM creates the page-viewports, and passes them on to
 1. the FLM --which controls layout of a subset of the areas
  generated by descendants of the fo:flow
  (ultimately also floats/footnotes)
 2. the SCLMs --which control layout of the areas generated
  by the descendants of the fo:static-contents
  (+ possible retrieved markers from the subset processed
  by the FLM)"

In this respect, the page-breaking logic is already at its most appropriate
place.
The FLM needs only a part of the total page-vp, so it makes sense to handle
the creation/initialization of the viewport one level up.

> > A more serious comment is that some formatting
> > objects (footnotes and before floats) generates
> > "page-level-out-of-line-areas", whose placement,
> > according to the recommendation (4.2.5), "is
> > controlled by the fo:page-sequence ancestor";

> As for "location controlled by the fo:page-sequence
> ancestor", that could simply mean that the
> fo:page-sequence defines the page margins and the side
> region dimensions.  The footnote is just "above" the
> region-after, and before-floats are just "below" the
> region-before, hence the fo:page-sequence determines
> its location.  This wouldn't necessarily mean that the
> actual layout of these objects needs to be done by the
> PSLM.

Indeed not. After all, both before-floats and footnotes *are* descendants of
an fo:flow (assigned to the region-body, IIC --see constraints for fo:float
w/ float="before" and footnotes(*))

> > so, if the PSLM must handle footnotes and before floats
> > (influencing the available bpd for the normal areas) it
> > must handle the whole page breaking process.
> >

No, the FLM must handle the footnotes and before-floats, but the PSLM must
handle the page-breaking...
Since the out-of-line objects are constrained to the flow (region-body), it
is not necessary to handle their processing higher up.

> Well, the available maximum bpd can be accessed from
> the  area.BodyRegion child of the PageViewport--this
> value is calculated automatically upon initialization
> of a PageViewport.  As you can see from section
> 6.10.1.3[1], these two areas consume space from the
> main-reference-area.  So it appears that all that
> would be necessary is for the FLM to create a
> PageViewport, and if a flow has a before-float or
> footnote, reduce that bpd for the regular
> normal-reference-areas.  (Also, to add the
> footnote/before-float separators in.)

The _creation_ of the page-viewports should be done by the PSLM, while
_dividing_ the assigned region-viewport's bpd over floats, footnotes and/or
block content is up to the FLM.

Cheers,

Andreas

(*) http://www.w3.org/TR/xsl/slice6.html#fo_float
http://www.w3.org/TR/xsl/slice6.html#fo_footnote

DO NOT REPLY [Bug 34354] - Not suported "menu"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34354





--- Additional Comments From [EMAIL PROTECTED]  2005-04-24 07:34 ---
(In reply to comment #5)
> (In reply to comment #4)
> > "How this(Menu)can be implemented in PDF in the first place" My 
> > answer is that I don't need implementation of it , I want only that Batik 
> > ignore it - it's not an error to use it.
>It is an error to use it.  You can not add arbitrary elements to
> the SVG namespace.  If the menu element were in another namespace
> (say Adobe something) Batik would ignore it and processes the elements
> in the SVG namespace but you can not place arbitrary elements in the SVG 
> namespace, it is a violation of the SVG specification.

The use of "menu" in Adobe can be explained in the following web site(there 
are examples to test) :
http://www.xml.com/pub/a/2002/07/03/adobesvg.html

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.