Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
Not an objection but a concern: I get the impression that more an more logic wanders off into the area package which should IMO only be a data structure plus serialization/deserialization and reference resolution. And I believe that column balancing is clearly the LMs responsibility. Especially with the Knuth approach this can't even be done otherwise. I don't know what the others think. On 30.03.2005 02:49:08 Glen Mazza wrote: > Team, > > I'd like to recommend next that we move the > initialization (*not* population) of the > page-reference-areas, region-viewport-areas, and > region-reference-areas from PSLM to area.PageViewport > (and possibly some in area.RegionViewport). IOW, > everything from line 685 to the end of the file > gone[1], with the remaining few lines of > createPageAreas() moved to makeNewPage(). > > This is all boilerplate routine setup--predefined > margin widths, etc-- independent of layout mechanisms, > and I suspect this work can be more cleanly and > orderly implemented in area.PageViewport anyway. > > Replacing this logic in PSLM eventually will be more > flow-mapping logic, both of the future fo:flow-map and > even our current 1.0 requirements to be able to place > fo:flow data into any of the region areas. (Perhaps > the column balancing as well, if the Span object > cannot handle it by itself.) This is more of PSLM's > responsibilities, and it will be quite large enough in > accomplishing all of them. But PSLM should more or > less be able to just call curPage = new > PageViewport(), and get a PageViewport with already > initialized child region areas. The coding to create > this IMHO will be a distraction if kept in PSLM. > > Any objections? > > Thanks, > Glen > > [1] http://tinyurl.com/4qca3 > > --- [EMAIL PROTECTED] wrote: > > > > gmazza 2005/03/29 16:06:30 > > > > Modified:src/java/org/apache/fop/area Tag: > > Temp_KnuthStylePageBreaking > > PageViewport.java > >src/java/org/apache/fop/layoutmgr > > Tag: > > Temp_KnuthStylePageBreaking > > > > PageSequenceLayoutManager.java > > Log: > > Removed the curSpan instance variable -- now > > obtainable via curPage. > > Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java
Team, I'd like to recommend next that we move the initialization (*not* population) of the page-reference-areas, region-viewport-areas, and region-reference-areas from PSLM to area.PageViewport (and possibly some in area.RegionViewport). IOW, everything from line 685 to the end of the file gone[1], with the remaining few lines of createPageAreas() moved to makeNewPage(). This is all boilerplate routine setup--predefined margin widths, etc-- independent of layout mechanisms, and I suspect this work can be more cleanly and orderly implemented in area.PageViewport anyway. Replacing this logic in PSLM eventually will be more flow-mapping logic, both of the future fo:flow-map and even our current 1.0 requirements to be able to place fo:flow data into any of the region areas. (Perhaps the column balancing as well, if the Span object cannot handle it by itself.) This is more of PSLM's responsibilities, and it will be quite large enough in accomplishing all of them. But PSLM should more or less be able to just call curPage = new PageViewport(), and get a PageViewport with already initialized child region areas. The coding to create this IMHO will be a distraction if kept in PSLM. Any objections? Thanks, Glen [1] http://tinyurl.com/4qca3 --- [EMAIL PROTECTED] wrote: > > gmazza 2005/03/29 16:06:30 > > Modified:src/java/org/apache/fop/area Tag: > Temp_KnuthStylePageBreaking > PageViewport.java >src/java/org/apache/fop/layoutmgr > Tag: > Temp_KnuthStylePageBreaking > > PageSequenceLayoutManager.java > Log: > Removed the curSpan instance variable -- now > obtainable via curPage. >
RE: Creating combined element lists for a table row from cell element lists
> -Original Message- > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > > Me: > > However, instead of mapping both possibilities to a > > structure with rows, we could go almost the other way > > round ... > > You may not have a first cell for every row. Take this example: > > table > table-body > table-row > cell rowspan=3 > cell rowspan=2 > table-row height=50 > table-row height=20 > cell > > In this example you don't have a first cell for the second row. > A more realistic example would be a dominant border in the > third row for the after edge. You need to have a way to collect all > relevant borders for each border segment and I currently don't see how > you would do that. Very good point indeed! I even think that *that* was the point where I eventually had to stop and breathe --slowly, to keep my head from over-heating :-) Anyway: agreed 1000% --yes, a thousand--, as long as one really needs an fo:table-cell node in the source document to trigger the instantiation of a TableCell (or subclass) FONode... I guess what I'm suggesting would, in your constructed example, come down to: table table-body cell rowspan=3 starts-row=true row-border=... border=... cell rowspan=2 border=... cell starts-row=true row-height=50 row-border=... cell starts-row=true row-height=20 row-border=... cell border=... The fact that the first of the above cells spans 3 rows, would mean that the third and fourth cells' *only* possible function is exactly to store the row's properties. We wouldn't lose these properties, they would just 'move' to a different location (and they would still be considered separately from the cell-particular properties --think of it as a cell with two 'bundles' of properties) BTW: the cells' column-number also appears to be pretty crucial in the approach I'm trying to describe... > I understand your idea but I don't see (yet) how this can work out. For > the moment anyway, I have a different problem. I still need too figure > out how to handle page breaking for tables in the Knuth model. This > seems to be a rather critical point to me ATM. Oh, of course. I just saw the opportunity to unleash some of my ideas, but I see now that it is indeed not really relevant to the initial topic of this thread --sorry 'bout the unnecessary distractions. > It all sounds nice and easy in theory but I'm currently > at a loss determining how to actually implement it in a > not too complicated way. Nothing you should be worrying about right now. Stay focused on whatever you're doing, and don't let it distract you too much --it's clear that I am the one who needs to give this more thought, while keeping a closer eye on what you're doing :-) Cheers, Andreas
Re: [VOTE] Release Transcoders
+1 from me. Regards, Simon On Fri, Mar 25, 2005 at 10:39:48AM +0100, Jeremias Maerki wrote: > Batik is currently preparing for a release (be that 1.5.1 or 1.6). > Former Batik releases simply contained a fop-transcoder.jar without > having been released properly. That's why I'm now calling for a formal > vote for a release of our transcoders. The only thing we do is tag CVS > HEAD, we don't publish the code ourselves. That also means that we're > not talking about releasing the whole codebase here, only the > transcoders plus their dependencies in our codebase (PDF lib, PS support > code, fonts and images). When the vote passes this tag must be used by > the Batik team to create their release. This should ensure that the > Batik release contains only clean code (meaning without known IP issues > and other showstoppers). > > This will be the last Batik release before we reorganize our two codebases > to create the XML Graphics Commons area. > > > Jeremias Maerki > -- Simon Pepping home page: http://www.leverkruid.nl
Re: Creating combined element lists for a table row from cell element lists
OK, I see. Thanks for the update. Glen --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Absolutely not. This whole thing here is exactly > about page breaking. > I'm just stuck at the moment. That's all. Luca now > gave me some new > input I'm currently playing through. As soon as we > figure out what > direction to take I'll resume coding. We're > currently at that bloody > critical point where it is decided if the Knuth > approach will really > work out or not. > > On 29.03.2005 16:40:49 Glen Mazza wrote: > > Jeremias, did you discontinue your work on the > page > > breaking? I missed the email. > > > Jeremias Maerki > >
Re: [VOTE] Release Transcoders
Jeremias Maerki wrote: Batik is currently preparing for a release (be that 1.5.1 or 1.6). Former Batik releases simply contained a fop-transcoder.jar without having been released properly. That's why I'm now calling for a formal vote for a release of our transcoders. The only thing we do is tag CVS HEAD, we don't publish the code ourselves. That also means that we're not talking about releasing the whole codebase here, only the transcoders plus their dependencies in our codebase (PDF lib, PS support code, fonts and images). When the vote passes this tag must be used by the Batik team to create their release. This should ensure that the Batik release contains only clean code (meaning without known IP issues and other showstoppers). +1 from me J.Pietschmann
RE: [VOTE] Release Transcoders
> -Original Message- > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > > ... I'm now calling for a formal vote for a release of our > transcoders. The only thing we do is tag CVS HEAD, ... (Seems I overlooked this one...) +1 Cheers, Andreas
Re: Creating combined element lists for a table row from cell element lists
Absolutely not. This whole thing here is exactly about page breaking. I'm just stuck at the moment. That's all. Luca now gave me some new input I'm currently playing through. As soon as we figure out what direction to take I'll resume coding. We're currently at that bloody critical point where it is decided if the Knuth approach will really work out or not. On 29.03.2005 16:40:49 Glen Mazza wrote: > Jeremias, did you discontinue your work on the page > breaking? I missed the email. Jeremias Maerki
Re: Creating combined element lists for a table row from cell element lists
Jeremias, did you discontinue your work on the page breaking? I missed the email. Glen --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Does anyone have any input on the issue of creating > Knuth elements for > tables? We talked about handling headers and footers > earlier and that > part is pretty clear to me. However, the part about > creating Knuth > elements for multi-column tables... I'm pretty > clueless ATM. I think > that my second approach could still work but it > seems very complicated > to implement and I think there's got to be an easier > solution which I > don't see ATM. > > Even looking at other layouting systems I get the > impression that they > are avoiding breaks inside table-cells. Lout for > example doesn't allow > it. Does anyone know how (and if) this is done > inside TeX? I don't get a > clue from looking at the TeXBook or the sources. > > > > Jeremias Maerki > >
Re: Creating combined element lists for a table row from cell element lists
On 29.03.2005 13:56:59 Luca Furini wrote: > Jeremias Maerki wrote: > > For those who want to join the mind game, > > here are the expected results from the broken lists: > > > > break at first legal break: > > Part 1 (height -> 15): > > Part 2 (height -> 41): > > > > break at second legal break: > > Part 1 (height -> 30): > > Part 2 (height -> 41): > > > > break at third legal break: > > Part 1 (height -> 33): > > Part 2 (height -> 15): > > > > break at fourth legal break: > > Part 1 (height -> 41): > > Part 2 (height -> 15): > > > > no breaks: > > Part 1 (height -> 45): > > This could be the procedure that creates the combined elements, at least > when there is no stretch nor shrink; I'm impressed! > with this assumption, the resulting > sequence will contain only boxes and penalties. I guess the sequence will have to be post-processed to add penalties for table-header/footer but that shouldn't be a problem. "before" and "after" cell borders will also be no big problem. Just saying this so we have the whole picture. > First of all, we must know the total height of the row, if it is not split > between pages. > > totalHeight = 0 > for each cell-list > height[i] = compute the total height of each cell-list > if (height[i] > totalHeight) > totalHeight = height[i] > > The sequence we are going to create must be totalHeight long when it is > not divided. > > step = 0 > addedBoxHeight = 0; > while step < totalHeight > step = nextStep() > penaltyHeight = step + maxRemainingHeight() - totalHeight > boxHeight = step - addedBoxHeight - penaltyHeight > addedBoxHeight += boxHeight > sequence.add(new box(boxHeight)) > sequence.add(new penalty(penaltyHeight, 0)) > > For each cell-list, we must know, besides the total height, the height of > the elements already combined into the new ones. > The nextStep() method looks at each cell-list, computing the height of the > first sub-sequence, chooses the smallest increase and updates in each list > the height of the elements already combined; maxRemainingHeight() returns > the greatest difference between the total height of a cell-list and the > height of the elements already combined. > > Using your example, the behaviour of this algorithm is this: > > totalHeight = 45 > > 1st step: step = 15 > maxRemaingHeight = 41 > addedBoxHeight = 0 > penaltyHeight = 15 + 41 - 45 = 11 > boxHeight = 15 - 0 - 11 = 4 > > 2nd step: step = 30 > maxRemaingHeight = 41 > addedBoxHeight = 4 > penaltyHeight = 30 + 41 - 45 = 26 > boxHeight = 30 - 4 - 26 = 0 > > 3rd step: step = 33 > maxRemaingHeight = 15 > addedBoxHeight = 4 > penaltyHeight = 33 + 15 - 45 = 3 > boxHeight = 33 - 4 - 3 = 26 > > 4th step: step = 41 > maxRemaingHeight = 15 > addedBoxHeight = 30 > penaltyHeight = 41 + 15 - 45 = 11 > boxHeight = 41 - 30 - 11 = 0 > > 5th step: step = 45 > maxRemaingHeight = 0 > addedBoxHeight = 30 > penaltyHeight = 45 + 0 - 45 = 0 > boxHeight = 45 - 30 - 0 = 15 > > > combined elements, with their width and what happens if a penalty is used: > > box 4 > penalty 11 > 15+41 > box 0 > penalty 26 > 30+41 > box 26 > penalty 3 > 33+15 > box 0 > penalty 11 > 41+15 > box 15 > 45 Wow. > I think this procedure could be quite easily extended in order to take > into account stretch and shrink. I'm not so sure. I agree that some degree of stretch and shrink we be no problem for the algorithm, but depending on the amount of shrinkability and stretchability you might get different step constellations you probably can't construct like this. We probably have to play a few scenarios through here. > > An alternative approach might be to do create "combined stretch boxes" > > (actually box+pen(inf)+glue) > > > > Cell1, combined stretch box: w=45000 y=3 z=0 > > Cell2, combined stretch box: w=3 y=15000 z=15000 > > Cell2a, combined stretch box: w=41000 y=8000 z=0 > > > > The combined stretch box for the whole row is easily calculated: > > > > row combined stretch box in both cases (2 and 2a) is: > > w=45000 y=3 z=0 > > > > The LM tries to fit as much as possible into the available area (similar > > to block-container with fixed BPD). The rest that doesn't fit at the end > > is deferred for the next page where a new combined stretch box is > > calculated. The consequence of this is the loss of look-ahead > > possibility, since the combined stretch box doesn't know how much can > > really fit on the previous page, and a new block list needs to be built. > > Yes, I think we should use this approach only if we don't find a better > one ... But still, we have to realize that the "combined list approach" cannot handle auto layout when there's different a
Re: Creating combined element lists for a table row from cell element lists
Just to answer this quickly: yes, page breaks inside table-rows (or rather table-cells) are allowed by default and you use keep-together when you don't want it split. The spec says: "The fo:table-cell formatting object generates one or more normal reference-areas." Keep-together's default is "auto" which allows breaks. Specifying height or block-progression-dimension (i.e. autoheight=false) might have the same result as a keep-together but we're not sure how exactly to handle this case. We talked about that two months ago. I'll work through the rest of your message shortly. On 29.03.2005 13:56:59 Luca Furini wrote: > Jeremias Maerki wrote: > > > I thought I could come up with a combined element list for this one, too, > > but so far I haven't managed. > > At last I'm here! > I start with a question I could not find an answer to: is row splitting > allowed by default and forbidden using keep-together, or is it forbidden > unless otherwise specified? (in other words, is this problematic situation > the most common one, or the most unlikely?) Jeremias Maerki
Re: Creating combined element lists for a table row from cell element lists
Jeremias Maerki wrote: > I thought I could come up with a combined element list for this one, too, > but so far I haven't managed. At last I'm here! I start with a question I could not find an answer to: is row splitting allowed by default and forbidden using keep-together, or is it forbidden unless otherwise specified? (in other words, is this problematic situation the most common one, or the most unlikely?) > For those who want to join the mind game, > here are the expected results from the broken lists: > > break at first legal break: > Part 1 (height -> 15): > Part 2 (height -> 41): > > break at second legal break: > Part 1 (height -> 30): > Part 2 (height -> 41): > > break at third legal break: > Part 1 (height -> 33): > Part 2 (height -> 15): > > break at fourth legal break: > Part 1 (height -> 41): > Part 2 (height -> 15): > > no breaks: > Part 1 (height -> 45): This could be the procedure that creates the combined elements, at least when there is no stretch nor shrink; with this assumption, the resulting sequence will contain only boxes and penalties. First of all, we must know the total height of the row, if it is not split between pages. totalHeight = 0 for each cell-list height[i] = compute the total height of each cell-list if (height[i] > totalHeight) totalHeight = height[i] The sequence we are going to create must be totalHeight long when it is not divided. step = 0 addedBoxHeight = 0; while step < totalHeight step = nextStep() penaltyHeight = step + maxRemainingHeight() - totalHeight boxHeight = step - addedBoxHeight - penaltyHeight addedBoxHeight += boxHeight sequence.add(new box(boxHeight)) sequence.add(new penalty(penaltyHeight, 0)) For each cell-list, we must know, besides the total height, the height of the elements already combined into the new ones. The nextStep() method looks at each cell-list, computing the height of the first sub-sequence, chooses the smallest increase and updates in each list the height of the elements already combined; maxRemainingHeight() returns the greatest difference between the total height of a cell-list and the height of the elements already combined. Using your example, the behaviour of this algorithm is this: totalHeight = 45 1st step: step = 15 maxRemaingHeight = 41 addedBoxHeight = 0 penaltyHeight = 15 + 41 - 45 = 11 boxHeight = 15 - 0 - 11 = 4 2nd step: step = 30 maxRemaingHeight = 41 addedBoxHeight = 4 penaltyHeight = 30 + 41 - 45 = 26 boxHeight = 30 - 4 - 26 = 0 3rd step: step = 33 maxRemaingHeight = 15 addedBoxHeight = 4 penaltyHeight = 33 + 15 - 45 = 3 boxHeight = 33 - 4 - 3 = 26 4th step: step = 41 maxRemaingHeight = 15 addedBoxHeight = 30 penaltyHeight = 41 + 15 - 45 = 11 boxHeight = 41 - 30 - 11 = 0 5th step: step = 45 maxRemaingHeight = 0 addedBoxHeight = 30 penaltyHeight = 45 + 0 - 45 = 0 boxHeight = 45 - 30 - 0 = 15 combined elements, with their width and what happens if a penalty is used: box 4 penalty 11 > 15+41 box 0 penalty 26 > 30+41 box 26 penalty 3 > 33+15 box 0 penalty 11 > 41+15 box 15 > 45 I think this procedure could be quite easily extended in order to take into account stretch and shrink. > An alternative approach might be to do create "combined stretch boxes" > (actually box+pen(inf)+glue) > > Cell1, combined stretch box: w=45000 y=3 z=0 > Cell2, combined stretch box: w=3 y=15000 z=15000 > Cell2a, combined stretch box: w=41000 y=8000 z=0 > > The combined stretch box for the whole row is easily calculated: > > row combined stretch box in both cases (2 and 2a) is: > w=45000 y=3 z=0 > > The LM tries to fit as much as possible into the available area (similar > to block-container with fixed BPD). The rest that doesn't fit at the end > is deferred for the next page where a new combined stretch box is > calculated. The consequence of this is the loss of look-ahead > possibility, since the combined stretch box doesn't know how much can > really fit on the previous page, and a new block list needs to be built. Yes, I think we should use this approach only if we don't find a better one ... > A point I still have to think about for both approaches is how exactly > to handle row spanning, although I suspect it'll be easier for the first > approach. I did not think about this yet, but I agree with you. Regards Luca
Re: Creating combined element lists for a table row from cell element lists
Does anyone have any input on the issue of creating Knuth elements for tables? We talked about handling headers and footers earlier and that part is pretty clear to me. However, the part about creating Knuth elements for multi-column tables... I'm pretty clueless ATM. I think that my second approach could still work but it seems very complicated to implement and I think there's got to be an easier solution which I don't see ATM. Even looking at other layouting systems I get the impression that they are avoiding breaks inside table-cells. Lout for example doesn't allow it. Does anyone know how (and if) this is done inside TeX? I don't get a clue from looking at the TeXBook or the sources. Jeremias Maerki
Re: [VOTE] Release Transcoders
Jeremias Maerki wrote: +1 from me too. +1 from me. The code has been stable over the last few months and seems to work well for most cases. I also don't see any other open issues preventing a release. On 25.03.2005 10:39:48 Jeremias Maerki wrote: Batik is currently preparing for a release (be that 1.5.1 or 1.6). Former Batik releases simply contained a fop-transcoder.jar without having been released properly. That's why I'm now calling for a formal vote for a release of our transcoders. The only thing we do is tag CVS HEAD, we don't publish the code ourselves. That also means that we're not talking about releasing the whole codebase here, only the transcoders plus their dependencies in our codebase (PDF lib, PS support code, fonts and images). When the vote passes this tag must be used by the Batik team to create their release. This should ensure that the Batik release contains only clean code (meaning without known IP issues and other showstoppers). Jeremias Maerki
