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, obviously. 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. :-) Arved --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
