Re: SpaceResolver usage
Hi, Jeremias Maerki a écrit : On 22.03.2007 11:41:28 Vincent Hennebert wrote: Hi, snip/ This raises the question as to how retained borders and paddings are handled: their widths will count in the penalty width of resolved break elements. How are borders from elements surrounding the list handled? Example: fo:block border-after-width.length=4pt border-after-width.conditionality=retain border-after-style=solid border-after-color=red fo:block-container fo:block border-after-width.length=4pt border-after-width.conditionality=retain border-after-style=solid border-after-color=blue some text... /fo:block /fo:block-container /fo:block IIUC the element list will be cut at the beginning of the block-container. Not cut. BlockContainerLM starts a new element list. Ok. How will the red border of the enclosing block be taken into account in the penalties produced by SpaceResolver on the list of elements inside the block-container? Not at all, since they don't interact according to the rules in 4.3.1: http://www.w3.org/TR/xsl11/#area-space Well, the width of the border from the outer block must still be considered. IIUC the inner block generates pending elements for its border-after, which will be converted by SpaceResolver into a Knuth penalty at each legal break of the sequence it generates, with a penalty length equal to the border width. At the outer block level, each penalty from subsequences must be modified to also take the border-after of the outer block into account. At least that's a way to implement things. Is that actually implemented that way? Vincent
DO NOT REPLY [Bug 41306] - AWT claims to support out-of-order: doesn't
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41306. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41306 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: svn commit: r521640 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/table/ColumnSetup.java test/layoutengine/standard-testcases/table-column_missing.xml
Jeremias, Author: jeremias Date: Fri Mar 23 02:19:04 2007 New Revision: 521640 URL: http://svn.apache.org/viewvc?view=revrev=521640 Log: Avoid an IndexOutOfBoundsException when more columns are used than are specified even though this is illegal with fixed table layout. What about our recent discussion on this topic? http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200703.mbox/[EMAIL PROTECTED] In the testcase you provided we would then rather raise a validation exception. Vincent
Re: svn commit: r521640 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/table/ColumnSetup.java test/layoutengine/standard-testcases/table-column_missing.xml
Sorry, I wasn't aware of that. I have trouble keeping up lately. I guess you're welcome to throw a ValidationException when strict validation is on and fixed table layout is in use. On 23.03.2007 12:30:02 Vincent Hennebert wrote: Jeremias, Author: jeremias Date: Fri Mar 23 02:19:04 2007 New Revision: 521640 URL: http://svn.apache.org/viewvc?view=revrev=521640 Log: Avoid an IndexOutOfBoundsException when more columns are used than are specified even though this is illegal with fixed table layout. What about our recent discussion on this topic? http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200703.mbox/[EMAIL PROTECTED] In the testcase you provided we would then rather raise a validation exception. Vincent Jeremias Maerki
Re: svn commit: r521640 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/layoutmgr/table/ColumnSetup.java test/layoutengine/standard-testcases/table-column_missing.xml
Jeremias Maerki a écrit : Sorry, I wasn't aware of that. I have trouble keeping up lately. That's ok, just wanted to be sure we were on the same track. I guess you're welcome to throw a ValidationException when strict validation is on and fixed table layout is in use. Something like that, yes. We would then have two methods of iterating over tables: one fast, memory-efficient relying on columns specifications, and one slow, memory-consuming parsing the entire table before doing anything else. Vincent On 23.03.2007 12:30:02 Vincent Hennebert wrote: Jeremias, Author: jeremias Date: Fri Mar 23 02:19:04 2007 New Revision: 521640 URL: http://svn.apache.org/viewvc?view=revrev=521640 Log: Avoid an IndexOutOfBoundsException when more columns are used than are specified even though this is illegal with fixed table layout. What about our recent discussion on this topic? http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200703.mbox/[EMAIL PROTECTED] In the testcase you provided we would then rather raise a validation exception. Vincent Jeremias Maerki
Re: AddAreas in RowPainter
On 19.03.2007 14:40:49 Vincent Hennebert wrote: Hi Jeremias, Thanks for your answers. Jeremias Maerki a écrit : On 17.03.2007 01:37:16 Vincent Hennebert wrote: Hi, There are things unclear to me in the addAreasAndFlushRow method of the RowPainter class. I hope someone can shed some light: I wrote this a long time ago. Let's hope I can dig some of it out again. - why is a Map used to store y-offsets of rows? That seems to indicate that rows are not added in a sequential order, or that there could be hole between them, which sounds unlikely to me. Frankly, I don't know anymore. Bad documenting on my part. The main reason I think was header and footer positioning because you first get the headers then you move to the body and finally do the footers. Since the areas generated by the table are reference areas they each have relative positioning (X and Y) inside the table. You can easily disable the offset map and see if you can make it run with only the yoffset variable. Don't have time to try it myself ATM. Sorry. Ok, after some further testing I figured out that some structure to store the y offsets of each row /is/ needed, but a List-like one should make the trick. This is needed because (by simplifying a bit) areas for cells are added once the end of the area is reached; if the cell spans over several rows we need to know what was the y-offset of the row where it begins. Right. Figured that out myself now. - there is one condition that I don't understand on l.204: in case the primary grid unit at the given column isn't null, then the corresponding areas are added only if: - forcedFlush == true, or - the end of the cell is reached on the current row AND (the current grid unit is null or is the last in the row-spanning direction). What's the purpose of that second member of the and? This is for situations like this: - an empty grid unit has to be painted - a cell could be empty (i.e. not providing any positions) - a cell that is broken over multiple pages has already contributed all its content on the previous page and does not contribute any new positions on the current position so we have to make sure the cell is painted all the same. Hmmm, I was thinking that if the corresponding primary grid unit is not null, this means that the cell begins on the current page. After removing the second part of the and all the tests still pass. Actually, there was a check missing which I added. Now you cannot remove that part anymore without breaking the tests. Removing that part causes one cell to be omitted. Grid units might not have been generated when there are no borders to paint. That's basically what the comment under line 204 says. Again you can comment some of the if and run the table test cases to see what happens. - also, inside the if branch, in case the primary grid unit was null, then the primary grid units from the current grid unit (i.e., on the current row) is retrieved if: - it does not correspond to an empty cell; - the cell doesn't span in the column direction - it is the last grid unit Why such conditions, and can the primary grid unit still be null after that (as implied by the if l.223)? I'd have to dive deeper into this one. There seems to be some careful selection of the cells to be painted, which is still a bit cryptic to me... What I can offer is to allocate some time next week (Wed or Fri) to better comment (and possibly refactor) the code there. At the time of Thanks. Commenting/explaining would be enough I think, because I'll probably have to refactor things anyway to implement collapsing-border model. I would be already less afraid of breaking things if the remaining uncertainties are cleared. You'll always have the tests. ;-) If you could also have a look at the while (offset == null) loop in the addAreasForCell method on l.247, that would be great. I believe it is not necessary, and again commenting it out doesn't make the tests fail. But perhaps you'll remember of why you wrote it in the first place and if it is still needed in some situation not covered by the tests. I agree that it is probably superfluous but since I want to be careful about touching running code I only put a comment there. An alternative would be an exception that tells the user no notify us (user tests). :-) snip/ Speaking of refactoring I'm thinking of avoiding null grid units and use some kind of flyweight pattern instead. There are plenty of places all over the code where they are tested for null, and I think it would simplify things (especially in the addAreas method, it seems). Just in case somebody has already thought about that and would have comments towards/against that... Makes sense. Jeremias Maerki (how's got to stop documenting code now)
Border conditionalities and collapsing-border model, breaks on header/footer
Guys, I've again stumbled upon uncertainties regarding the handling of conditional borders in the collapsing-border model, and breaks inside headers/footers. I'd like to have your opinions on these: Table headers and footers: Headers and footers are generated only once, and replicated on each page. This means that cells in headers and footers only generate one area, with the is-first and is-last traits set. Border- and padding-conditionality don't apply here. Or perhaps that the border-before of the table should still be considered? I mean, for the first header it would come into play, and for following headers it also would only if conditionality=retain. I think I'll go that way as it more closely matches the behavior of the separate border-model. Table body(-ies): There are several uncertainties: - should the border-before of the table and table-columns be considered or not: do we consider that those borders only apply to the very first (or last) row of the table? Or also to the first (last) row on each page? The question remains whether there are headers/footers or not. I would say yes. - when we break /within/ a cell, should the following row come into play for computing the border-after? As the row hasn't even been reached yet, I'd say no. - when we break at a grid line, should the two rows meeting a the line count in border resolution? Or only the row before for the border-after at the end of the page, and the row after for the border-before at the beginning of the following page? I would go with that latter. - when we break at a grid line, should the entire border appear on each page, or the higher half at the bottom of the first page, and the lower half at the top of the following page? I would also go with that latter. Tables and breaks: - do breaks on headers and footers make sense? Obviously not, excepted perhaps a break-before on the header's first row, or a break-after on the footer's last row. But as the same effect can be achieved by putting the breaks on the fo:table object, I think breaks on headers/footers should be entirely discarded. Opinions? Thanks, Vincent
Re: Border conditionalities and collapsing-border model, breaks on header/footer
BTW, don't forget to use the Wiki as resource. Simon and I documented various cases (including the tricky ones) here: http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder2 http://people.apache.org/~jeremias/fop/KnuthBoxesForTablesWithBorders.pdf (The PDF has multiple examples, the last page shows the simplified approach which does not take interaction between body and headers into account when resolving borders) On 23.03.2007 16:54:37 Jeremias Maerki wrote: On 23.03.2007 15:44:57 Vincent Hennebert wrote: Guys, I've again stumbled upon uncertainties regarding the handling of conditional borders in the collapsing-border model, and breaks inside headers/footers. I'd like to have your opinions on these: Table headers and footers: Headers and footers are generated only once, and replicated on each page. This means that cells in headers and footers only generate one area, with the is-first and is-last traits set. Border- and padding-conditionality don't apply here. Conditionality still applies but because there's a header or footer serving as fence, the cell borders and paddings don't get discarded. Different wording, but essentially, yes. Or perhaps that the border-before of the table should still be considered? I mean, for the first header it would come into play, and for following headers it also would only if conditionality=retain. I think I'll go that way as it more closely matches the behavior of the separate border-model. There's no table border in the collapsing border model when we're talking about areas. All levels of borders inside a table are merged. In the end, all you have are cell borders, nothing else. Only in separate border model do you have separate borders on the table and on the cells. Table body(-ies): There are several uncertainties: - should the border-before of the table and table-columns be considered or not: do we consider that those borders only apply to the very first (or last) row of the table? Or also to the first (last) row on each page? The question remains whether there are headers/footers or not. I would say yes. http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that. The image should help you understand. An example: take the before border of the first cell of a table header. The elements that influence the resolved borders are: table, column-groups if applicable, the column, table-header, the first row in the table-header and the cell itself. All the borders of these elements have to be combined. That's what's already (!) implemented in CollapsingBorderModelEyeCatching (for border-collapse=collapse) - when we break /within/ a cell, should the following row come into play for computing the border-after? As the row hasn't even been reached yet, I'd say no. Right. That's the case in CollapsingBorderModelEyeCatching when currentCell is not null, and otherCell is null. - when we break at a grid line, should the two rows meeting a the line count in border resolution? Or only the row before for the border-after at the end of the page, and the row after for the border-before at the beginning of the following page? I would go with that latter. That's right. - when we break at a grid line, should the entire border appear on each page, or the higher half at the bottom of the first page, and the lower half at the top of the following page? I would also go with that latter. No, the entire border has to be painted. This is BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the renderers. See the BorderProps class. Tables and breaks: - do breaks on headers and footers make sense? Obviously not, excepted perhaps a break-before on the header's first row, or a break-after on the footer's last row. But as the same effect can be achieved by putting the breaks on the fo:table object, I think breaks on headers/footers should be entirely discarded. Yes, breaks in headers and footers make no sense and should be ignored. Opinions? Thanks, Vincent Jeremias Maerki Jeremias Maerki
Re: Percentages in CommonAbsolutePosition?
On Mar 23, 2007, at 11:22, Vincent Hennebert wrote: Thanks for your perseverance ;-) You're welcome. :o) snip / If the nearest ancestor ref-area is not immediately visible, then I think this implies that the fixed-area's position is definitely not relative to the viewport you refer to, but to another nested viewport. Then which one? If there is no block-container in the flow, then the only viewport area is the region-body. And my question remains... OK, take the region-body as an example, with overflowing content and a fixed-positioned block-container that is a descendant of a block that initially falls outside the region-viewport, and thus is not immediately visible. Same as an absolute-positioned block-container, it will appear at a certain position in the region-viewport-area (regardless of where it was specified, or whether the containing block is visible or not). For our current output-targets, the story ends here, because there is no scrolling. Note that an absolute-positioned block-container will always appear, even if the containing block ends up on a part that is clipped (never visible). OTOH, if the fixed-positioned block-container is enclosed by a regular one, then its initial visibility depends on the initial visibility of the regular block-container, precisely because the regular block-container establishes a new viewport/reference-area pair. The fixed-positioned one will appear as a static part in that new viewport once it becomes visible. snip / As the idea is probably to mimic the absolute and fixed value for position in CSS2, I think the description of fixed should not refer to the one of absolute for placing areas. They should have written something like These properties specify offsets with respect to the page's viewport area. The term page seems too narrow here. Your suggestion would only cover the case of absolute- or fixed-positioned areas whose nearest ancestor ref-area is the page-area. No, what I was saying is that the position would be computed WRT to the ancestor page-area (more precisely, the region-reference-area) instead of the nearest ancestor ref-area, whatever it is. Why? I think that would actually make it more difficult than it is now, since a nested block-container would then also need to get at the containing page, whereas now it is enough to stop at the first block-container that establishes the reference area. Cheers, Andreas
Re: Border conditionalities and collapsing-border model, breaks on header/footer
Jeremias Maerki a écrit : On 23.03.2007 15:44:57 Vincent Hennebert wrote: Guys, I've again stumbled upon uncertainties regarding the handling of conditional borders in the collapsing-border model, and breaks inside headers/footers. I'd like to have your opinions on these: Table headers and footers: Headers and footers are generated only once, and replicated on each page. This means that cells in headers and footers only generate one area, with the is-first and is-last traits set. Border- and padding-conditionality don't apply here. Conditionality still applies but because there's a header or footer Why would conditionality apply? Every area from headers would have is-first set. serving as fence, the cell borders and paddings don't get discarded. Different wording, but essentially, yes. Or perhaps that the border-before of the table should still be considered? I mean, for the first header it would come into play, and for following headers it also would only if conditionality=retain. I think I'll go that way as it more closely matches the behavior of the separate border-model. There's no table border in the collapsing border model when we're talking about areas. All levels of borders inside a table are merged. In the end, all you have are cell borders, nothing else. I know, the question is for the border-before of (the first row of) the header: for the very first header, border-before on table and table-columns play in the border resolution. Should they also for the headers on the following pages? Only in separate border model do you have separate borders on the table and on the cells. Table body(-ies): There are several uncertainties: - should the border-before of the table and table-columns be considered or not: do we consider that those borders only apply to the very first (or last) row of the table? Or also to the first (last) row on each page? The question remains whether there are headers/footers or not. I would say yes. http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that. The image should help you understand. An example: take the before border of the first cell of a table header. The elements that influence the resolved borders are: table, column-groups if applicable, the column, table-header, the first row in the table-header and the cell itself. All the borders of these elements have to be combined. That's what's already (!) implemented in CollapsingBorderModelEyeCatching (for border-collapse=collapse) That doesn't tell anything regarding page breaks!? If the table is broken across several pages and the header shall be replicated, do border-before for table and table-column play again in border-resolution for the second and following headers? Or only for the first one? That's the same question as above actually. And that also applies to the first row from the table-body on each page, when header should be omitted at page breaks. - when we break /within/ a cell, should the following row come into play for computing the border-after? As the row hasn't even been reached yet, I'd say no. Right. That's the case in CollapsingBorderModelEyeCatching when currentCell is not null, and otherCell is null. Fine. - when we break at a grid line, should the two rows meeting a the line count in border resolution? Or only the row before for the border-after at the end of the page, and the row after for the border-before at the beginning of the following page? I would go with that latter. That's right. Fine (that means that the border may potentially be different at the bottom of the previous page and at the top of the next page). Do we agree that those two latter cases are not described by the spec? - when we break at a grid line, should the entire border appear on each page, or the higher half at the bottom of the first page, and the lower half at the top of the following page? I would also go with that latter. No, the entire border has to be painted. This is BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the renderers. See the BorderProps class. So the grid line at the page break would have two borders, one at the bottom of the page, one at the top of the next page? That's fine for me, but again I think it's specified nowhere. Tables and breaks: - do breaks on headers and footers make sense? Obviously not, excepted perhaps a break-before on the header's first row, or a break-after on the footer's last row. But as the same effect can be achieved by putting the breaks on the fo:table object, I think breaks on headers/footers should be entirely discarded. Yes, breaks in headers and footers make no sense and should be ignored. Great. Opinions? Thanks, Vincent Jeremias Maerki Thanks, Vincent
Re: Border conditionalities and collapsing-border model, breaks on header/footer
On Mar 23, 2007, at 18:21, Vincent Hennebert wrote: [Jeremias: ] snip / http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that. snip / The image should help you understand. An example: take the before border of the first cell of a table header. The elements that influence the resolved borders are: table, column-groups if applicable, the column, table-header, the first row in the table-header and the cell itself. All the borders of these elements have to be combined. That's what's already (!) implemented in CollapsingBorderModelEyeCatching (for border-collapse=collapse) That doesn't tell anything regarding page breaks!? Hèhè, that always tends to happen with references to CSS. :-) If the table is broken across several pages and the header shall be replicated, do border-before for table and table-column play again in border- resolution for the second and following headers? YES! Not only border-before even, I think, but that is open for interpretation. The column's border-before *and* after need to be considered for each body, header/footer that appears on a given page. One could also argue that the column's span the entire table for each page, so the column's border-after does not need to be considered for the header's last row, for instance. Apart from that, there is the tiny note, of course, that we're talking about hypothetical situations, in which border-conditionality is overridden for all table-elements. The default value being discard makes the interplay between border- collapse and border-conditionality actually much simpler than it seems at first... snip / - when we break at a grid line, should the two rows meeting a the line count in border resolution? Or only the row before for the border-after at the end of the page, and the row after for the border-before at the beginning of the following page? I would go with that latter. That's right. Fine (that means that the border may potentially be different at the bottom of the previous page and at the top of the next page). Only if you have no header/footer. If there is a repeated header/ footer, then the border will neatly be the same for all pages. If you have no header or footer, then overriding border-*- width.conditionality on the table or table-body is enough to prevent weird effects. Do we agree that those two latter cases are not described by the spec? As far as I remember, yes, since XSL-FO refers almost entirely to CSS (which, because of its correlation with HTML, has no concept of page- breaks). This still leaves some room for the implementors FTM... - when we break at a grid line, should the entire border appear on each page, or the higher half at the bottom of the first page, and the lower half at the top of the following page? I would also go with that latter. No, the entire border has to be painted. This is BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the renderers. See the BorderProps class. So the grid line at the page break would have two borders, one at the bottom of the page, one at the top of the next page? That's fine for me, but again I think it's specified nowhere. Hmm... not exactly. Think of the part of the table on one page as an independent subgrid, that has nothing to do anymore with the preceding or following subgrid. It is the gridline which is split in two, and each of the new gridlines will have one fully resolved border. In a sense the border is duplicated, yes... :/ Cheers, Andreas
