Re: Getting breaks: revisited
J.Pietschmann wrote: Peter B. West wrote: ...the intention of the spec would be realised by laying out 0 of the repeatable-p-m-refs thin, out of the available range of 0-100, then laying out 1 of the thick r-p-m-refs. Interesting and useful interpretation. The problem is, how to implement this? Joerg, It depends on your overall method of generating areas. This goes to overall design questions, which are on hold until we have had a chance to consider the Sun product, but if layout is driven from below (as in a sense it already is), with tentative layouts bubbling upwards until they strike an invalidating constraint, which then follows them back down the tree for a retry, and all of this eventually comes back up to the PageMaker level, then, in the case above, the result would be a no-can-do, accompanied by the dimensions of the best attempt. The PageMaker would then look for a layout master alternative, discarding the remainder of the repetitions in the process, and having a go at the thick master. That succeeds. If it didn't the fallback mode would be determined by the overflow property. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
J.Pietschmann wrote: Victor Mote wrote: Just to be clear, I should point out that there is not a layout that is impossible to perform. There are layouts for which it is very hard to decide what to do. Consider the following: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=thin page-width=110mm page-height=297mm fo:region-body/ /fo:simple-page-master fo:simple-page-master master-name=thick page-width=210mm page-height=297mm fo:region-body/ /fo:simple-page-master fo:page-sequence-master master-name=master fo:repeatable-page-master-reference maximum-repeats=100 master-reference=thin/ fo:repeatable-page-master-reference master-reference=thick/ /fo:page-sequence-master /fo:layout-master-set fo:page-sequence master-reference=master fo:flow flow-name=xsl-region-body fo:block width=150mmblabla../fo:block /fo:flow /fo:page-sequence /fo:root Should this create 100 empty pages and render the text onto the 101st page, or should it squeeze it onto the first page, thereby violating the advised width constraint of the block? The user could have either in mind. Joerg, I kept this one in my inbox, and have finally got back to it. I would have thought that in a case like this, the intention of the spec would be realised by laying out 0 of the repeatable-p-m-refs thin, out of the available range of 0-100, then laying out 1 of the thick r-p-m-refs. This would work in the same way for the other case you mention - constrained height and keep-together table rows. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
Peter B. West wrote: ...the intention of the spec would be realised by laying out 0 of the repeatable-p-m-refs thin, out of the available range of 0-100, then laying out 1 of the thick r-p-m-refs. Interesting and useful interpretation. The problem is, how to implement this? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
On Tue, 2002-12-03 at 21:56, J.Pietschmann wrote: Oleg Tkachenko wrote: btw, how does such a case addressed by the spec? Apparently FOP, antenna and xep do squeeze content. Isn't it an example of overconstrained geometry (5.3.4)? It can be interpreted as such in the presented case. Use height instead of width and a table whose rows are kept together instead of a block to make it more interesting (from the users point of view, for the processor it may still be an example of overconstrained geometry, but this becomes far fetched rapidly). That suggests to me that the spec needs some work. How can it possible mean that it should go through every single possible combination of pages/blank pages to come up with a suitable solution. Does the area tree allow for multiple breaks between areas in the flow? (not including forced breaks) It doesn't say either way (that I can find) but I would hope the answer is no. Then you could say that anything that starts on the page will ensure that some of it is placed on the page. The keeps are dealt within the context of that page (and further flow) until a forced break but not in terms of an arbitrary future page that might fit the current content. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
Oleg Tkachenko wrote: btw, how does such a case addressed by the spec? Apparently FOP, antenna and xep do squeeze content. Isn't it an example of overconstrained geometry (5.3.4)? It can be interpreted as such in the presented case. Use height instead of width and a table whose rows are kept together instead of a block to make it more interesting (from the users point of view, for the processor it may still be an example of overconstrained geometry, but this becomes far fetched rapidly). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
J.Pietschmann wrote: There are layouts for which it is very hard to decide what to do. Consider the following: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=thin page-width=110mm page-height=297mm fo:region-body/ /fo:simple-page-master fo:simple-page-master master-name=thick page-width=210mm page-height=297mm fo:region-body/ /fo:simple-page-master fo:page-sequence-master master-name=master fo:repeatable-page-master-reference maximum-repeats=100 master-reference=thin/ fo:repeatable-page-master-reference master-reference=thick/ /fo:page-sequence-master /fo:layout-master-set fo:page-sequence master-reference=master fo:flow flow-name=xsl-region-body fo:block width=150mmblabla../fo:block /fo:flow /fo:page-sequence /fo:root Should this create 100 empty pages and render the text onto the 101st page, or should it squeeze it onto the first page, thereby violating the advised width constraint of the block? btw, how does such a case addressed by the spec? Apparently FOP, antenna and xep do squeeze content. Isn't it an example of overconstrained geometry (5.3.4)? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
Victor Mote wrote: Just to be clear, I should point out that there is not a layout that is impossible to perform. There are layouts for which it is very hard to decide what to do. Consider the following: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=thin page-width=110mm page-height=297mm fo:region-body/ /fo:simple-page-master fo:simple-page-master master-name=thick page-width=210mm page-height=297mm fo:region-body/ /fo:simple-page-master fo:page-sequence-master master-name=master fo:repeatable-page-master-reference maximum-repeats=100 master-reference=thin/ fo:repeatable-page-master-reference master-reference=thick/ /fo:page-sequence-master /fo:layout-master-set fo:page-sequence master-reference=master fo:flow flow-name=xsl-region-body fo:block width=150mmblabla../fo:block /fo:flow /fo:page-sequence /fo:root Should this create 100 empty pages and render the text onto the 101st page, or should it squeeze it onto the first page, thereby violating the advised width constraint of the block? The user could have either in mind. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Hi Rhett, On Wed, 2002-11-20 at 16:44, Rhett Aultman wrote: I may be green, but I did spot some of this a couple weeks ago, and it went mostly unnoticed. While writing this email, I downloaded another CVS snapshot and the super-simple test document from bug #8778, which is probably the simplest of all the i-loop cases, and ran it again...it's the same thing I saw when I last brought this up. Give me a chance, it is by no means finished and to suggest that if it doesn't do it properly now it never will is going a bit far. Currently it does not handle the situation where it cannot find any normal break in a page, so if the page is small it will get an infinite loop. I have never said it will handle anything you throw at it. I am talking about design anyway. The design will handle that situation. Easy: there is currently no best break (ie. it is null) therefore we still need to find a break. So the best break will be after the block. It will place that on the page and finish document. If there are keeps it should probably go further until it can be sure it will find the best breaks for all things kept together. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Responses below. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 3:08 AM To: FOP Subject: RE: Getting breaks: revisited Hi Rhett, On Wed, 2002-11-20 at 16:44, Rhett Aultman wrote: I may be green, but I did spot some of this a couple weeks ago, and it went mostly unnoticed. While writing this email, I downloaded another CVS snapshot and the super-simple test document from bug #8778, which is probably the simplest of all the i-loop cases, and ran it again...it's the same thing I saw when I last brought this up. Give me a chance, it is by no means finished and to suggest that if it doesn't do it properly now it never will is going a bit far. I'm not suggesting that. I am, however, attempting to explore potential solutions. I'm asking you what you intend to do about it, since you have insisted that the various ideas offered are either bad or unnecessary. Currently it does not handle the situation where it cannot find any normal break in a page, so if the page is small it will get an infinite loop. I have never said it will handle anything you throw at it. I am talking about design anyway. The design will handle that situation. I'm talking about design, too. This entire thread is about design. I'm citing examples because they elucidate a general, design-related issue. To be frank, saying the design will handle this is much like saying the proof is left as an example for the reader. I'm attempting to explore *how* such a design would from a general position. This is a highly relevant topic. Victor, Peter, and I have all offered ideas of ways to resolve such matters, and you too seem to have more musings on it. I'd enjoy hearing them. Do you have a general solution for discarding constraints that get in the way of layout? Easy: there is currently no best break (ie. it is null) therefore we still need to find a break. So the best break will be after the block. It will place that on the page and finish document. If there are keeps it should probably go further until it can be sure it will find the best breaks for all things kept together. IIRC, in my 8778 experiment, the break being offered was never null. The best break is always being offered, but the best break is at the beginning of the offending block. Either way, this resolves only the most trivial of the examples without paying attention to the greater issue, which is that such layout issues are rooted in constraints that conflict. Is your intention to wait for such cases to come in and just write special-case code for each and every one of them at the time? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
On Thu, 2002-11-21 at 14:20, Rhett Aultman wrote: IIRC, in my 8778 experiment, the break being offered was never null. The best break is always being offered, but the best break is at the beginning of the offending block. Either way, this resolves only the most trivial of the examples without paying attention to the greater issue, which is that such layout issues are rooted in constraints that conflict. Is your intention to wait for such cases to come in and just write special-case code for each and every one of them at the time? No, in the design the best break cannot be before the block, there is no break before everything on the page. It doesn't matter how many constraints there are, there will always be a best break on the page that will place some contents on the page. The next page will therefore have less to layout and will also place some contents on its page, therefore an infinite loop is impossible. Now to find the best break. This could simply be done within the context of the current page. Best break is: - at least first available break - of a lower keep constraint - closer to the optimum page bpd Now to extend that to a more general situation. It will need to find every break in the page sequence and compare the constraints that are broken. Then attempt to adjust those breaks so fewer constraints are broken. So how will this be done. The PageLayoutManager can collect all best breaks as they are created. Then look at the constraints and available moving room. I can't define any specifics because I would need to think about it more. But I am certain there would be some sort of formula that could aid in this process. Like: this page has optimum spacing and breaks no constraints - therefore it can only be adjust between min and max spacing. This page break is less than the min and the next page breaks within an always keep so it should attempt to break the keep on the first page and get closer to opt distance while having a normal break on the next page. Of course a force page break is definite so it could segment parts of the flow, do the layout and add the pages. Why do you think that it cannot be extended to handle this. The question to me is how to organise this in a good way that does not mean using lots of memory and processing at many levels while still being able to handle the tricky parts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Responses below. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 9:11 AM To: FOP Subject: RE: Getting breaks: revisited On Thu, 2002-11-21 at 14:20, Rhett Aultman wrote: No, in the design the best break cannot be before the block, there is no break before everything on the page. When you say in the design, do you mean that this is expected behavior as it is now or as it should be at some point in the future? It doesn't matter how many constraints there are, there will always be a best break on the page that will place some contents on the page. The next page will therefore have less to layout and will also place some contents on its page, therefore an infinite loop is impossible. I hear what you're saying, and this should ideally seem correct, but if this is the way that things are now, I think that what is happening and what is ideally happening are out of touch with one another. Now to extend that to a more general situation. It will need to find every break in the page sequence and compare the constraints that are broken. Then attempt to adjust those breaks so fewer constraints are broken. I believe this is not far from what was being suggested ala the concept of a layout plan. This is also not far from what I was describing earlier when I talked about first gathering up all of the information about various constraints and page breaks and then applying decisions about what is to be done. The name of the game is spotting the issues before they're run into. Why do you think that it cannot be extended to handle this. I think that a system that has full knowledge of proposed breaks and constraints and can make and enforce decisions about when and how to pick and choose should he able to. It hasn't seemed like you've been interested in following that route. The question to me is how to organise this in a good way that does not mean using lots of memory and processing at many levels while still being able to handle the tricky parts. Yes, but I don't think we should dwell on that for too long. Getting something that handles the tricky parts is more important in my mind than worrying about optimization. In my experience, optimization solutions become obvious once the implementation is found to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
On Thu, 2002-11-21 at 16:03, Rhett Aultman wrote: When you say in the design, do you mean that this is expected behavior as it is now or as it should be at some point in the future? That's the point of the original message, currently it doesn't do it quite right. I am looking to adjust it to do this when there is a good concept of how so that it will do the right thing sometime in the future. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
On Tue, 2002-11-19 at 16:57, Rhett Aultman wrote: I'm not sure how writing the thing to make two passes is more loop prone than making one pass, especially if each pass performs a different function. For example, what if the first pass was designed only to gather information about the proposed layout options and the second pass was the actual process of layout, getting the opportunity to make its decisions from on high with total knowlege? I can't really see what you could find out on a first pass that does not do some sort of layout. I suppose it is a question of what exactly we mean. Currently it sort of does more than one pass, but only the first pass reads the fo and sorts out most of the layout. When it is reset then it will reflow the inlines, lines and blocks. An idea I am thinking of is reseting based on change of page or ipd. So that it is possible to only reflow what is needed, the rest we a simply re-reading the current breaks and making a break decision from that. Yes, and I think that the system works pretty well for a lot of situations. I'm not suggesting that it get chucked to the weeds. A question this begs, though, is that is this design going to take us the whole way through? In your own email here you bring up two cases where a LM's decisions have to be dependant upon more than just its own children. Well it is hard to say really. But I will say that it is important to continue to publicly demonstrate progress. I am sure the current design has the potential to do more than the current simplistic situation, to me it is a question of how to do it cleanly. Also, this may seem like an issue only to me, but I our next layout system must be free of infinite loops. It is essential that enterprise users know their Tomcat or jBoss servers are not going to have to be restarted if some guy makes a screwup in his Servlet or MBean and accidentally triggers a special case in FOP that leads to a layout loop. A process for recognizing when a constraint must be lifted in order to ensure the document processes is necessary, and I think it was Victor (though maybe Peter...) who pointed out that such a process leads to another problem- if you lift a constraint in one place, you have effects on the layout of the entire document, too. In order to handle this problem, the entire layout system needs the ability to not only spot the issue but to select the best resolution for it and then layout according to that decision. I hate infinite loops just as much as the everyone else. I think that it is currently far less prone to the problem and I intend to continue to ensure it won't happen. I've spent a lot of mental energy over the last several days trying to come up with a solution, and the only one I've come up with thus far involves creating a tree of alternative layout choices. For an ideal document, there really isn't a tree. For less-than-ideal ones, there would be a branch of the tree at every place a violation occurs, and there decisions would branch off with possibilities of how to resolve the problem. If a decision creates even more woes, its branch would get deeper and deeper. Finding the ideal set of choices to make in resolving an issue then becomes a matter of simply finding the shortest branch in a tree. This is, in many ways, in parallel with the LayoutPlan approach previously mentioned. But, to do this, they layout system needs to start out with a certain base set of knowlege about the layout of the document, and to me this implies that multiple passes are needed. Maybe only one final layout pass is needed, and the current, tree-based layout mechanism would probably be a shoe in there. Once the high-level decisions are made, it should be easy for the present layout mechanism to follow them. Whatever the shape this takes, I still see a need for some forms of redesign of the current layout system, if for no reason other than I don't think that tweaks and special cases are enough to prevent the layout managers from getting caught in endless loops. As I've said before, I feel like I'm just spouting hoohah, so take this with a grain of salt, but I think more mechanisms are needed in the layout system than what's being offered are necessary, and I'd rather have a slow and complex but loop-free and complete LM than a fast and simple but loop-prone and incomplete one. The best thing I can say is: understand the issues and start doing it. I'm not saying that we shouldn't indeed make a complete tree of the document and decide the best breaks. I just don't think that enforcing that situation is a good idea when we could layout the first page when there is a force page break or no keeps. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Responses Below. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 3:38 AM To: FOP Subject: RE: Getting breaks: revisited I can't really see what you could find out on a first pass that does not do some sort of layout. I suppose it is a question of what exactly we mean. Currently it sort of does more than one pass, but only the first pass reads the fo and sorts out most of the layout. When it is reset then it will reflow the inlines, lines and blocks. Well, let's take the idea that we were starting at square one with respect to LM development. One possibly strategy would be to make a pass over all of the objects to be laid out, visiting each one and, while not laying it out, gathering information about what explicit constraints each one is under. Armed with this information, a layout system could create a plan for reconciling all constraints, even dropping constraints if they were in conflict. This is essentially the same thing as the LayoutPlan concept mentioned by other developers. The first pass isn't really a layout pass but a sort of scouting out issues relevant to the layout process. I could see how this sort of scouting ahead could help resolve even some of the issues you mentioned, such as footnotes throwing monkey wrenches in the system. Maybe this is what you mean when you say the first pass reads the fo and sorts out most of the layout, and we just have our wires crossed. An idea I am thinking of is reseting based on change of page or ipd. So that it is possible to only reflow what is needed, the rest we a simply re-reading the current breaks and making a break decision from that. The problem, as I see it, is that those breaks aren't always trustworthy. My stripped down FO document in bug #8778 had the same problem in HEAD that it does in maintenance (at least, it did a few weeks ago). A problem is in the cases where the LM offers breaks where it thinks they should best be put, but choosing the breaks in that fashion prevents the content from actually getting laid out anywhere. A few weeks ago, you expressed disbelief that this was happening, but I know what I was seeing and I know what I did to terminate the loop, and I offered to show you the experiment I'd run at my desk. Maybe things have been shored up since then, since that was weeks ago, in which case my point is moot. Well it is hard to say really. But I will say that it is important to continue to publicly demonstrate progress. I am sure the current design has the potential to do more than the current simplistic situation, to me it is a question of how to do it cleanly. Right...I'm agreeing wholeheartedly there, but I'm asking about some issues that I don't see being addressed in the layout system in HEAD. You seem very steadfast in the belief that the design for layout in HEAD, as it is, is all that we need, and so I'm curious as to how you think it will address issues like the one I'm bringing up. If it won't, then what I am proposing is that the layout system as it is in HEAD is a critical tool in a much larger process of layout and that more layout tools are needed to work with it. I hate infinite loops just as much as the everyone else. I think that it is currently far less prone to the problem and I intend to continue to ensure it won't happen. The very simple loop-causing document I put in bug #8778 seems to me to be a fundamental demonstration of how constraints in conflict create loops. A simple case like this one shows nearly identical behavior between maintenance and HEAD. Though it's much easier in HEAD to code an LM to spot the characteristic lack of progress and try to break out of the cycle, I don't see how this can be used to address the real issue- the fact that two disparite constraints contradict each other. The best thing I can say is: understand the issues and start doing it. I may be green, but I did spot some of this a couple weeks ago, and it went mostly unnoticed. While writing this email, I downloaded another CVS snapshot and the super-simple test document from bug #8778, which is probably the simplest of all the i-loop cases, and ran it again...it's the same thing I saw when I last brought this up. I'm not saying that we shouldn't indeed make a complete tree of the document and decide the best breaks. I just don't think that enforcing that situation is a good idea when we could layout the first page when there is a force page break or no keeps. Well, maybe there's a balance to be struck, but my test document on bug #8778 has no keeps and, despite the space-before being enough to nudge content into spilling off the page and triggering a break before the block, is incredibly simple, yet the LM system is skewered by the contradicting complaints. I guess what I'm asking is what thoughts you have on solving this issue in a general fashion, since I can definitely see that, if a simple
RE: Getting breaks: revisited
On Sat, 2002-11-16 at 09:21, Rhett Aultman wrote: It seems to me that there are (at least) two approaches: 1. A leaf on the tree says I am here, put me somewhere on a page, or 2. A higher-level node (page-sequence) says I have some space here, send me something to fill it. 3. 1 + 2. Thinking that you can do 1. in isolation is, well, brain-dead. On the other hand, how does 2. handle auto table layout? The columns cannot be dimensioned at the very top until the last information about requirements is in from the very bottom. Then the decision is taken at the top, and percolates all the way back down again. I agree that there's a combination of both approaches are necessary, but I'm not sure how 1 handles auto table layout all that much better. I did just wake up over an on-call issue, so maybe it's grogginess, but wouldn't auto-layout either way require reading the whole table first to divine column widths? I will concede that, under option 2, it's not clear if the table will fit in the proffered space until after the entire table is processed, meaning that a purely 2 system is doing a LOT of looking ahead, just to keep up with itself. Is this the handicap of the second option you're referring to? Under the first option, the table can take care of itself, then demand to be placed somewhere, which has the benefit of less looking down the road but the deficit that there may not be room for it anywhere. What if, instead, two passes were taken? The first pass would be for trying to find space for all of the objects with hard-and-fast space and size needs, and then the second pass would place objects that are more malleable. By taking two passes, it'd be possible to first divine the size of auto-layout tables, for example. Like I said...it's late and I was roused from bed, so I may have not really thought about this as much as I should, but this is brainstorming... If possible I think we should try to avoid making multiple passes since it can lead to loops etc. The table layout auto will need at least two passes but this should be possible using the layout managers. The general concept of layout managers is that a layout manager deals with the breaks that the child layout managers create. So that it can group together breaks when there is a keep together and only return one break to the parent LM which is allowed against the keeps. This can then be extended to the situation where it needs to break within that keep, it will return the best available break. The parent can then deal with it appropriately. I think the idea is sound but there are some implementation questions about dealing with keep with previous and other situations. Now the real problems. What happens for footnotes. A footnote takes space from the main reference area. So we need some way of calculating the remaining space given a potential footnote and the inline area (or line) that adds the footnote. Do we pass the information all the way to the top and then get an answer or is there some other way that the calculation can be achieved where it is needed. Before you say thats simple, just subtract it from the body bpd, well what happens if the footnote is inside a page column. The height that the columns require needs to be calculated by balancing the columns with the currently available areas, then you find the space remaining with the footnote. There are alos situations where the footnote is added where the whole block must be added. Then it must wait until the block is complete before saying if the block and footnote can fit. Sometimes it needs to make a calculation with an abritrary ancestor other times it needs to hold until another ancestor finds a valid break before know if it will fit. So how do we deal with all these things without making it really slow and complicated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
Keiron Liddle wrote: On Sat, 2002-11-16 at 09:21, Rhett Aultman wrote: It seems to me that there are (at least) two approaches: 1. A leaf on the tree says I am here, put me somewhere on a page, or 2. A higher-level node (page-sequence) says I have some space here, send me something to fill it. 3. 1 + 2. Thinking that you can do 1. in isolation is, well, brain-dead. On the other hand, how does 2. handle auto table layout? The columns cannot be dimensioned at the very top until the last information about requirements is in from the very bottom. Then the decision is taken at the top, and percolates all the way back down again. I agree that there's a combination of both approaches are necessary, but I'm not sure how 1 handles auto table layout all that much better. I did just wake up over an on-call issue, so maybe it's grogginess, but wouldn't auto-layout either way require reading the whole table first to divine column widths? I will concede that, under option 2, it's not clear if the table will fit in the proffered space until after the entire table is processed, meaning that a purely 2 system is doing a LOT of looking ahead, just to keep up with itself. Is this the handicap of the second option you're referring to? Under the first option, the table can take care of itself, then demand to be placed somewhere, which has the benefit of less looking down the road but the deficit that there may not be room for it anywhere. What if, instead, two passes were taken? The first pass would be for trying to find space for all of the objects with hard-and-fast space and size needs, and then the second pass would place objects that are more malleable. By taking two passes, it'd be possible to first divine the size of auto-layout tables, for example. Like I said...it's late and I was roused from bed, so I may have not really thought about this as much as I should, but this is brainstorming... If possible I think we should try to avoid making multiple passes since it can lead to loops etc. The table layout auto will need at least two passes but this should be possible using the layout managers. Is that a should be or an is? Given your recent concerns about the rapidly increasing complexity of your design, do you have a feasible solution for auto layout? Multiple passes - in some sense - are unavoidable. This is most obvious in the case of auto layout, as described in the CSS documentation which is the actual reference for this stuff. The general concept of layout managers is that a layout manager deals with the breaks that the child layout managers create. So that it can group together breaks when there is a keep together and only return one break to the parent LM which is allowed against the keeps. This can then be extended to the situation where it needs to break within that keep, it will return the best available break. The parent can then deal with it appropriately. I think the idea is sound but there are some implementation questions about dealing with keep with previous and other situations. Now the real problems. What happens for footnotes. A footnote takes space from the main reference area. So we need some way of calculating the remaining space given a potential footnote and the inline area (or line) that adds the footnote. Do we pass the information all the way to the top and then get an answer or is there some other way that the calculation can be achieved where it is needed. Before you say thats simple, just subtract it from the body bpd, well what happens if the footnote is inside a page column. The height that the columns require needs to be calculated by balancing the columns with the currently available areas, then you find the space remaining with the footnote. There are alos situations where the footnote is added where the whole block must be added. Then it must wait until the block is complete before saying if the block and footnote can fit. Sometimes it needs to make a calculation with an abritrary ancestor other times it needs to hold until another ancestor finds a valid break before know if it will fit. You have, of course, read my notes on this topic. If, by some mischance, you have not, you'll find them in the alt.design section of the web page. When you get around to migrating it to forrest, that is. When is that likely to be, by the way? So how do we deal with all these things without making it really slow and complicated. I would suggest just getting it working. If that ever happens, 1) I will be pleasantly surprised 2) you can then worry about making it faster. If it doesn't happen, then, when I have finished my work on properties, I will design and implement the layout engine, and it *will* work. Before then, however, the whole exercise may have been rendered academic by Sun. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go?
Re: Getting breaks: revisited
On Tue, 2002-11-19 at 15:07, Peter B. West wrote: If possible I think we should try to avoid making multiple passes since it can lead to loops etc. The table layout auto will need at least two passes but this should be possible using the layout managers. Is that a should be or an is? Given your recent concerns about the rapidly increasing complexity of your design, do you have a feasible solution for auto layout? There is no is until it starts working, I haven't tried to do it yet. You have, of course, read my notes on this topic. If, by some mischance, you have not, you'll find them in the alt.design section of the web page. When you get around to migrating it to forrest, that is. When is that likely to be, by the way? Yes I have read it, but it doesn't exactly explain the specifics. Also doing certain things for each line area, yes it could work, no I don't like the possible results. Well there is no one stopping you from migrating them. So how do we deal with all these things without making it really slow and complicated. I would suggest just getting it working. If that ever happens, 1) I will be pleasantly surprised 2) you can then worry about making it faster. I could just do it, special cases can use special techniques provided it doesn't effect normal cases too much. If it doesn't happen, then, when I have finished my work on properties, I will design and implement the layout engine, and it *will* work. Before then, however, the whole exercise may have been rendered academic by Sun. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
Keiron Liddle wrote: On Tue, 2002-11-19 at 15:07, Peter B. West wrote: If possible I think we should try to avoid making multiple passes since it can lead to loops etc. The table layout auto will need at least two passes but this should be possible using the layout managers. Is that a should be or an is? Given your recent concerns about the rapidly increasing complexity of your design, do you have a feasible solution for auto layout? There is no is until it starts working, I haven't tried to do it yet. There is no possible when it starts working. You have, of course, read my notes on this topic. If, by some mischance, you have not, you'll find them in the alt.design section of the web page. When you get around to migrating it to forrest, that is. When is that likely to be, by the way? Yes I have read it, but it doesn't exactly explain the specifics. Also doing certain things for each line area, yes it could work, no I don't like the possible results. Well there is no one stopping you from migrating them. You broke it; you fix it. So how do we deal with all these things without making it really slow and complicated. I would suggest just getting it working. If that ever happens, 1) I will be pleasantly surprised 2) you can then worry about making it faster. I could just do it, special cases can use special techniques provided it doesn't effect normal cases too much. In my view, and here we differ, auto layout is not a special case. It is the litmus test of the design. I believe that the design can and should be such that the easy cases are special, simplified, cases of the general solution. If it doesn't happen, then, when I have finished my work on properties, I will design and implement the layout engine, and it *will* work. Before then, however, the whole exercise may have been rendered academic by Sun. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Respone below. -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 5:06 AM To: FOP Subject: RE: Getting breaks: revisited On Sat, 2002-11-16 at 09:21, Rhett Aultman wrote: What if, instead, two passes were taken? The first pass would be for trying to find space for all of the objects with hard-and-fast space and size needs, and then the second pass would place objects that are more malleable. By taking two passes, it'd be possible to first divine the size of auto-layout tables, for example. Like I said...it's late and I was roused from bed, so I may have not really thought about this as much as I should, but this is brainstorming... If possible I think we should try to avoid making multiple passes since it can lead to loops etc. The table layout auto will need at least two passes but this should be possible using the layout managers. I'm not sure how writing the thing to make two passes is more loop prone than making one pass, especially if each pass performs a different function. For example, what if the first pass was designed only to gather information about the proposed layout options and the second pass was the actual process of layout, getting the opportunity to make its decisions from on high with total knowlege? The general concept of layout managers is that a layout manager deals with the breaks that the child layout managers create. So that it can group together breaks when there is a keep together and only return one break to the parent LM which is allowed against the keeps. Yes, and I think that the system works pretty well for a lot of situations. I'm not suggesting that it get chucked to the weeds. A question this begs, though, is that is this design going to take us the whole way through? In your own email here you bring up two cases where a LM's decisions have to be dependant upon more than just its own children. What happens for footnotes. A footnote takes space from the main reference area. So we need some way of calculating the remaining space given a potential footnote and the inline area (or line) that adds the footnote. Do we pass the information all the way to the top and then get an answer or is there some other way that the calculation can be achieved where it is needed. Before you say thats simple, just subtract it from the body bpd, well what happens if the footnote is inside a page column. The height that the columns require needs to be calculated by balancing the columns with the currently available areas, then you find the space remaining with the footnote. This is what I meant, too, when I said that there are cases where the concern does not behave in perfect, unidirectional tree-like fashion, which tells me that there's design considerations to make, and maybe going outside of the box and thinking of the current tree of LMs as one part of the solution is indicated. So how do we deal with all these things without making it really slow and complicated. Keeping it from getting complicated is definitely important, but I'm willing to accept slow in the name of also getting correct. Also, this may seem like an issue only to me, but I our next layout system must be free of infinite loops. It is essential that enterprise users know their Tomcat or jBoss servers are not going to have to be restarted if some guy makes a screwup in his Servlet or MBean and accidentally triggers a special case in FOP that leads to a layout loop. A process for recognizing when a constraint must be lifted in order to ensure the document processes is necessary, and I think it was Victor (though maybe Peter...) who pointed out that such a process leads to another problem- if you lift a constraint in one place, you have effects on the layout of the entire document, too. In order to handle this problem, the entire layout system needs the ability to not only spot the issue but to select the best resolution for it and then layout according to that decision. I've spent a lot of mental energy over the last several days trying to come up with a solution, and the only one I've come up with thus far involves creating a tree of alternative layout choices. For an ideal document, there really isn't a tree. For less-than-ideal ones, there would be a branch of the tree at every place a violation occurs, and there decisions would branch off with possibilities of how to resolve the problem. If a decision creates even more woes, its branch would get deeper and deeper. Finding the ideal set of choices to make in resolving an issue then becomes a matter of simply finding the shortest branch in a tree. This is, in many ways, in parallel with the LayoutPlan approach previously mentioned. But, to do this, they layout system needs to start out with a certain base set of knowlege about the layout of the document, and to me this implies that multiple passes are needed. Maybe only one final layout pass
RE: Getting breaks: revisited
Response below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Getting breaks: revisited Keiron Liddle wrote: I could just do it, special cases can use special techniques provided it doesn't effect normal cases too much. In my view, and here we differ, auto layout is not a special case. It is the litmus test of the design. I believe that the design can and should be such that the easy cases are special, simplified, cases of the general solution. I would have to agree. If fighting complexity is the concern, the special techniques for special cases code must be kept to an absolute minimum. Special case code pretty much generates complexity on its own. Something like auto layout of tables should be treated as part of the general layout solution, if for no reason other than the fact that nearly everyone who makes a table in FO is going to want to use auto layout (or, in the case of newcomers, defaults to it). If table auto layout seems to be falling under the heading of special case under the current design, it may be a clue that the design needs to be rethought. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Response Below. -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: Friday, November 15, 2002 7:25 PM To: [EMAIL PROTECTED] Subject: Re: Getting breaks: revisited Victor Mote wrote: It seems to me that there are (at least) two approaches: 1. A leaf on the tree says I am here, put me somewhere on a page, or 2. A higher-level node (page-sequence) says I have some space here, send me something to fill it. 3. 1 + 2. Thinking that you can do 1. in isolation is, well, brain-dead. On the other hand, how does 2. handle auto table layout? The columns cannot be dimensioned at the very top until the last information about requirements is in from the very bottom. Then the decision is taken at the top, and percolates all the way back down again. I agree that there's a combination of both approaches are necessary, but I'm not sure how 1 handles auto table layout all that much better. I did just wake up over an on-call issue, so maybe it's grogginess, but wouldn't auto-layout either way require reading the whole table first to divine column widths? I will concede that, under option 2, it's not clear if the table will fit in the proffered space until after the entire table is processed, meaning that a purely 2 system is doing a LOT of looking ahead, just to keep up with itself. Is this the handicap of the second option you're referring to? Under the first option, the table can take care of itself, then demand to be placed somewhere, which has the benefit of less looking down the road but the deficit that there may not be room for it anywhere. What if, instead, two passes were taken? The first pass would be for trying to find space for all of the objects with hard-and-fast space and size needs, and then the second pass would place objects that are more malleable. By taking two passes, it'd be possible to first divine the size of auto-layout tables, for example. Like I said...it's late and I was roused from bed, so I may have not really thought about this as much as I should, but this is brainstorming... In the much more constrained context of Lout, Jeffrey Kingston describes the back and forward movement of the layout logic in, e.g., Section 2.5 of The Design and Implementation of the Lout Formatting Language http://snark.ptc.spbu.ru/~uwe/lout/design.pdf. Fascinating little reference. Thanks! Again, I am ignorant (although I have read the related doc), but reading between the lines makes me think that we are driven to the first option, which I am betting makes dealing with the higher-level layout issues very complicated. I'm also surmising that we probably can't do a good job (or at least can't *know* that we did) until we get the entire page-sequence read anyway, which means that we might be better off reading it in before we start then taking the second approach. FWIW. Actually, I hope to learn a lot from Keiron's replies. Likewise. I'm in agreement there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Getting breaks: revisited
Hi Developers, The current way that breaks are found with the layout managers has a couple of problems. Currently the information is contained in both the layout managers and the break positions. This means that it must follow the order: get breaks: add areas: get breaks etc. So columns are not possible. The other problem is there is no good way to indicate that the end of the page has been reached. (there are a few other problems that stem from this) So it needs to be adjusted a bit in order to make the process simpler and more localised. What I am thinking is to: - each layout manager adds breaks to a local list and returns and stores information about the break - it returns the last/best break, which contains why it is the last, forced, end page, end contents - the best break is found - once found each layout manager only knows that the best break is within a particular child layout manager - the best break is added to a list within each layout manager that contains the best break This way it can continue to find breaks independent of previous breaks. It can restart at a particular break, using the previous breaks if nothing has change (ipd or page) and open the possibility for disposing of layout managers and breaks that have been added to a page. At the moment I am finding it is getting too complicated and messy. So does that sound right. (does anyone even know what I am talking about) Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
On Friday 15 November 2002 09:30, Keiron Liddle wrote: . . .(does anyone even know what I am talking about) Not much on my side as the whole layout thing is still a mystery to me (because I have no experience in computing layouts and never took the time to study this part the code in detail). Anyway I'll try to put my 2 cents in... From your description, I get a feeling that a separate BreaksManager class might be needed, i.e. it might be better making this break stuff modular instead of making the layout managers more complex. I told you...just 2 cents ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
On 15 Nov 2002 09:30:17 +0100 Keiron Liddle wrote: So does that sound right. (does anyone even know what I am talking about) :-) It sounds reasonable from a very high point of view. I hope I will soon be able to join this kind of discussion. From next week on I'll be a free man for a few months. Without payment, but free. :-) I have my last working day today and I'm looking forward to spend a lot of time with FOP redesign in the following weeks. Well, certainly not fulltime, but as much as possible. By the way, I can recommend to everyone to take a couple of months or more off between jobs. I've done that before, am doing it now and it is most refreshing. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
On Fri, 2002-11-15 at 09:42, Bertrand Delacretaz wrote: On Friday 15 November 2002 09:30, Keiron Liddle wrote: . . .(does anyone even know what I am talking about) Not much on my side as the whole layout thing is still a mystery to me (because I have no experience in computing layouts and never took the time to study this part the code in detail). Anyway I'll try to put my 2 cents in... From your description, I get a feeling that a separate BreaksManager class might be needed, i.e. it might be better making this break stuff modular instead of making the layout managers more complex. Could be an option, get the common break handling/storing into a separate class that does that work. Complexity creep is a real problem in this area and that could make things easier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Comments below. -Original Message- From: Keiron Liddle [mailto:keiron;aftexsw.com] Sent: Friday, November 15, 2002 3:30 AM To: FOP Subject: Getting breaks: revisited The current way that breaks are found with the layout managers has a couple of problems. Currently the information is contained in both the layout managers and the break positions. This means that it must follow the order: get breaks: add areas: get breaks etc. So columns are not possible. The other problem is there is no good way to indicate that the end of the page has been reached. (there are a few other problems that stem from this) There is one more problem you need to put in there- under the current system, there is no mechanism for determining if the layout instructions in an FO document will produce a document that cannot exist. At least, there's none I've seen. Most of the bugs posted regarding infinite loops are caused by the same thing- the layout is impossible to perform, but FOP does not detect this and simply continues doing the same thing over and over again- get a fresh page, try to lay out, get breaks, get a fresh page... I haven't extensively tried all the infinite loop bugs on HEAD, but I have tried a few and they continue to have this problem. This really needs to be addressed from a design perspective. This way it can continue to find breaks independent of previous breaks. It can restart at a particular break, using the previous breaks if nothing has change (ipd or page) and open the possibility for disposing of layout managers and breaks that have been added to a page. While the actual process you're proposing is still gelling in my mind and I don't quite grok it fully, your implications here are enticing. I especially like the idea of being able to restart at a previous break and what that might mean for catching aberrant conditions. As I've said before, the only current way I see for catching layouts that infinitely spawn pages is to implement code in each LM that causes the LM to check itself and see if it's making any progress, leading to an Exception if no progress is made in many pages. It's not a good solution, and being able to roll back to a previous break may give the layout system a little more self awareness. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
Keiron Liddle wrote: Hi Developers, The current way that breaks are found with the layout managers has a couple of problems. Currently the information is contained in both the layout managers and the break positions. This means that it must follow the order: get breaks: add areas: get breaks etc. So columns are not possible. The other problem is there is no good way to indicate that the end of the page has been reached. (there are a few other problems that stem from this) So it needs to be adjusted a bit in order to make the process simpler and more localised. What I am thinking is to: - each layout manager adds breaks to a local list and returns and stores information about the break - it returns the last/best break, which contains why it is the last, forced, end page, end contents - the best break is found - once found each layout manager only knows that the best break is within a particular child layout manager - the best break is added to a list within each layout manager that contains the best break This way it can continue to find breaks independent of previous breaks. It can restart at a particular break, using the previous breaks if nothing has change (ipd or page) and open the possibility for disposing of layout managers and breaks that have been added to a page. At the moment I am finding it is getting too complicated and messy. So does that sound right. (does anyone even know what I am talking about) Keiron, Some disclaimers. I have been thinking along my own lines about layout, as you know, and that makes it very much harder to pick up someone else's very different line of thought. I have also been deeply involved with properties and the FO tree build for some time now, so I simply have not had time to focus on what you are doing with layout. All this means that I have not had time to read any of your code, and have only skimmed your documentation, so I may be missing the obvious. With all those disclaimers, let me suggest that you take the time to draw your layout ideas, both at a large scale, and, when you are pondering detailed questions like this, at a small scale. A picture is worth a thousand lines of code, and anyone with restricted time to get across your ideas will be drawn (so to speak) into them much more quickly. I know it's time consuming; I have just a day preparing a couple of diagrams of low to moderate complexity. So much for the plug for diagrams. I don't know whether my notes on laying out columns in the presence of footnotes will be of any use to you, and I suppose that you have read them before. I don't know what you are talking about, and do not understand, e.g., why you don't know when the end of a page has been reached. A shortcut to an understanding of such things would be very useful. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Response below. -Original Message- From: Victor Mote [mailto:vic;outfitr.com] Sent: Friday, November 15, 2002 1:48 PM To: [EMAIL PROTECTED] Subject: RE: Getting breaks: revisited Just to be clear, I should point out that there is not a layout that is impossible to perform. The standard allows (and would have to) implementation-specific handling of what they call over-constrained requirements. In other words, requirements can be prioritized and allowed to slip when they are contradictory or impossible. True, and that was what I meant to refer to. Thank you for the clarification. Still, I think that before a decision that something has to give can be made, the layout has to be recognized for being impossible under the user-given constraints. I think we're on the same wavelength here. From a design standpoint, the best ideas I have seen/heard revolve around some scoring system. I think the HZ program, TeX, and Lout all use this approach. To do this, you would need for each break manager to return not just the best break, but a collection of possible breaks with some ranking mechanism. Ideally, somebody at the highest level (page-sequence) decides what is best, based on information that percolates up from the lower levels. This implies to me that we can see the entire page-sequence sub-tree at one time, which may not be true in our SAX event-based model. It seems that the page-sequence would attempt to lay itself out using the best breaks that came up from sub-nodes, then adjust if over-constrained, perhaps with the concept of a layout Plan or Proposal. I like the fundamentals of this idea as well, but I also can't help but wonder if there might not be other options. Perhaps a system where LMs report to their parents on how well they're doing their jobs, allowing issues to percolate up the tree? If the LM system can go back to past breaks as Keiron was talking about, then it might be possible to lay everything out as per normal and, when an issue gets raised, to revert back to some past break, analyze what caused the issue, remove an offending constraint, and go back to work. Granted, this is not as cool a solution as a planned layout system (ala your suggestion), but if generating a layout plan requires more omniscience than the SAX event-based model provides, then a sort of rollback mechanism may be a sufficient alternative. Hm...and what about a fusion of the two. If the LMs submitted potential breaks and some sort of information about the constraint that has to be removed to use them, and this information was held on to, then at some point down the line in processing, FOP could rewind back to a past break and select from the next best list...essentially meaning that FOP flies blind until there's a problem, then goes back and examines a plan of alternate routes, and after picking one, goes with it and gets back to work as usual. Is any of this making sense, or is this all just a bunch of hoohah? I know it is easier said than done, and may already be done. Please pardon my ignorance of the current design. I would offer it as my $.02 worth, but someone would want a nickel change ($.05). I dunno. I was playing around with a HEAD snapshot a few weeks back, and did run one of the infinite looping bugs on bugzilla against it and found that I could get the LMs to lock in a loop by doing something as simple as creating a block containing unhyphenatable text that was larger than the bodies of all the specified pages. This tells me that if there is a system in place to protect against over-constrained layouts, it's not there yet. I'd played with a fix on it that allowed the LM closest to the action (a TextLayoutManager) keep track of how many characters in its string it had successfully laid out and, if it didn't progress after 100 tries, halting. Obviously, we don't want to go with that. -- Rhett. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Getting breaks: revisited
Rhett Aultman wrote: Hm...and what about a fusion of the two. If the LMs submitted potential breaks and some sort of information about the constraint that has to be removed to use them, and this information was held on to, then at some point down the line in processing, FOP could rewind back to a past break and select from the next best list...essentially meaning that FOP flies blind until there's a problem, then goes back and examines a plan of alternate routes, and after picking one, goes with it and gets back to work as usual. Is any of this making sense, or is this all just a bunch of hoohah? IMHO, not hoohah. That is exactly what I was driving at. The issue, of course, is that next best might be in an entirely different context than it was before. For example, a line-breaking strategy might have reported next best based on the assumption that it was working in a space 4.5 wide, but because of an issue with a footnote, a higher-level LM has now pushed it to the following page where it is next to a graphic that only leaves it 2.5 to work with. So now the layout needs to be recomputed for that line entirely. So now you have to basically keep track of the options that you have tried, with the scoring opportunities for each one. You basically have to try options until you find one that scores acceptably or until there are no others to try, at which point, you take the best one that you have. It seems to me that there are (at least) two approaches: 1. A leaf on the tree says I am here, put me somewhere on a page, or 2. A higher-level node (page-sequence) says I have some space here, send me something to fill it. Again, I am ignorant (although I have read the related doc), but reading between the lines makes me think that we are driven to the first option, which I am betting makes dealing with the higher-level layout issues very complicated. I'm also surmising that we probably can't do a good job (or at least can't *know* that we did) until we get the entire page-sequence read anyway, which means that we might be better off reading it in before we start then taking the second approach. FWIW. Actually, I hope to learn a lot from Keiron's replies. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Getting breaks: revisited
Victor Mote wrote: Just to be clear, I should point out that there is not a layout that is impossible to perform. The standard allows (and would have to) implementation-specific handling of what they call over-constrained requirements. In other words, requirements can be prioritized and allowed to slip when they are contradictory or impossible. Yes, but that still leaves some very difficult problems, especially where last-page, footnotes and floats are concerned. From a design standpoint, the best ideas I have seen/heard revolve around some scoring system. I think the HZ program, TeX, and Lout all use this approach. To do this, you would need for each break manager to return not just the best break, but a collection of possible breaks with some ranking mechanism. Ideally, somebody at the highest level (page-sequence) decides what is best, based on information that percolates up from the lower levels. This implies to me that we can see the entire page-sequence sub-tree at one time, which may not be true in our SAX event-based model. It seems that the page-sequence would attempt to lay itself out using the best breaks that came up from sub-nodes, then adjust if over-constrained, perhaps with the concept of a layout Plan or Proposal. So scrap SAX. Or, to be more precise, reduce SAX to the role of XML event server to a top-down tree builder, which in turn provides event notification and read-only tree access to the top-down layout engine. I know it is easier said than done, Definitely. and may already be done. Well, the part about reducing SAX to an event server has already been done, and the part about building the FO tree top-down is almost finished. The last bit, unfortunately, has not even been started. I was getting ready to post some details about this, but I wanted to finish the creation of the FO objects first. I will now post them this weekend. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
