Responses below.

> -----Original Message-----
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
> Sent: December 10, 2002 5:56 AM
> To: FOP
> Subject: RE: Redesign issues
> Hi Arved,
> On Mon, 2002-12-09 at 20:30, Arved Sandstrom wrote:
> > The feeling I got from my prototype is that there is not much
> commonality.
> >
> > Markers - there is no logic here that has anything to do with
> layout, per
> > se. The content goes into a static-content and hence does not
> influence page
> > break decisions. The logic for handling markers can be confined to the
> > document level. "root" is an FO - it is the document, so it is
> the FO that
> > can handle this.
> That is true but there is something that happened in the original way
> that fop handled markers.
> The fo has a property list which has a parent property list from the
> parent object. It also has a parent object. It couldn't be simply made
> null and then passed to the root as it could cause npe's.
> The argument here is not so much that it cannot be done, more that if it
> is a completely separate logic then it is easier to understand and
> ensure it won't end up with bugs or memory leaks.

Right...I implemented the original (incomplete) marker logic using what we
had at the time for property handling. I did not tackle the re-parenting
problem at all - didn't get that far - so the marker content actually
retained the inherited properties from the origin FO, which is incorrect.

I see no problems with a marker handler that associates with the document,
in this case. This would coordinate with page-sequences and pages,

Incidentally, I still think that the way markers are described in the spec
is vague and confusing. Perhaps we should hammer this out.

> > Floats and footnotes - the float goes on a page or it doesn't.
> The footnote
> > starts on page N and continues through N+x or it doesn't. What FO knows
> > about pages? The "page-sequence"...that's the natural FO for
> handling float
> > and footnote problems. OK, this is somewhat simplified; with
> floats it may
> > come down to columns, and then it is the "region-body" that
> also needs to
> > intercede.
> >
> > Tables I can't comment on. So there may be an argument here for
> independent
> > layout managers.
> >
> > I think we could use layout managers when it is clear that
> there is a layout
> > problem involving N FOs, such that those N FOs are not identical to the
> > children of a higher FO. I see keeps as being the main
> occurrence of this.
> > But even then, keeps are still related to logic that occurs in
> page-sequence
> > and region-body and lines (3 entities, in other words), and the
> nature of
> > that logic differs in all 3 situations, so is it worth abstracting out a
> > keep manager? I don't know.

> There is the line layout manager. There is no line fo. The block layout
> manager is able to collect inline porducing layout managers and give
> them to a line layout manager which then has the logic to handle flowing
> inline areas into a line.
> The block layout logic is then more simple.

Lines are not FO's, no - that's why I used the word "entity". :-)

> This is similar to the cells under a table body.
> Also with page columns, do we want to make the FlowLayout manager handle
> all the blocks that do and don't span columns or can we create a page
> column layout manager which looks after blocks in columns and then can
> handle the reflowing etc.

I originally handled this (in my prototype) with managers for pages,
regions, spans and columns. This is the one area where I think managers make
the most sense - the handling of a page is complex and it simplifies matters
to have clearly distinguishable managers to take care of the various
constituent areas.

> A leader with use-content creates an inline parent with a fixed width.
> It is creating a simple inline area but we want to do a quick
> independant layout for the content.
> Again, maybe not necessary but it help separate out the logic.
> > Here's a common ground that I can agree on...pull the layout
> logic out, and
> > put it in "managers". This is not going to hurt. But really,
> really cut down
> > on the urge to re-use managers through an inheritance hierarchy. I think
> > this is also Joerg's point. It obfuscates more than it helps.
> I'm not sure the exact re-use problem you are referring to but I agree
> it should be simple and straight forward.

Agreed. I won't comment further until I re-sync with the latest CVS and
examine. :-)


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to