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