[jira] [Updated] (FOP-1581) Improve border painting in collapsing border model
[ https://issues.apache.org/jira/browse/FOP-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dian hina updated FOP-1581: --- oke finish > Improve border painting in collapsing border model > -- > > Key: FOP-1581 > URL: https://issues.apache.org/jira/browse/FOP-1581 > Project: FOP > Issue Type: Improvement > Components: unqualified >Affects Versions: 2.5 > Environment: Operating System: All > Platform: All >Reporter: Vincent Hennebert > Attachments: border-painting.fo > > > See attached file: the corners adjacent to the cell without borders aren't > fully painted, which makes the result not very nice. > It would be a nice to have if the borders were fully painted, like in the > separate border model (second table). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1581) Improve border painting in collapsing border model
[ https://issues.apache.org/jira/browse/FOP-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bowditch updated FOP-1581: Attachment: (was: az-900-Exam-Dumps-2019.pdf) > Improve border painting in collapsing border model > -- > > Key: FOP-1581 > URL: https://issues.apache.org/jira/browse/FOP-1581 > Project: FOP > Issue Type: Improvement > Components: unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Vincent Hennebert > Attachments: border-painting.fo > > > See attached file: the corners adjacent to the cell without borders aren't > fully painted, which makes the result not very nice. > It would be a nice to have if the borders were fully painted, like in the > separate border model (second table). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FOP-1581) Improve border painting in collapsing border model
[ https://issues.apache.org/jira/browse/FOP-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] victoriavargas updated FOP-1581: Attachment: az-900-Exam-Dumps-2019.pdf > Improve border painting in collapsing border model > -- > > Key: FOP-1581 > URL: https://issues.apache.org/jira/browse/FOP-1581 > Project: FOP > Issue Type: Improvement > Components: unqualified >Affects Versions: trunk > Environment: Operating System: All > Platform: All >Reporter: Vincent Hennebert > Attachments: az-900-Exam-Dumps-2019.pdf, border-painting.fo > > > See attached file: the corners adjacent to the cell without borders aren't > fully painted, which makes the result not very nice. > It would be a nice to have if the borders were fully painted, like in the > separate border model (second table). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
DO NOT REPLY [Bug 45924] Improve border painting in collapsing border model
https://issues.apache.org/bugzilla/show_bug.cgi?id=45924 --- Comment #2 from Glenn Adams gl...@skynav.com 2012-04-07 01:42:45 UTC --- resetting P2 open bugs to P3 pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45924] Improve border painting in collapsing border model
https://issues.apache.org/bugzilla/show_bug.cgi?id=45924 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 36934] The collapsing border model on an fo:table is currently not supported by FOP
https://issues.apache.org/bugzilla/show_bug.cgi?id=36934 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from Glenn Adams gl...@skynav.com 2012-04-01 06:45:23 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45924] Improve border painting in collapsing border model
https://issues.apache.org/bugzilla/show_bug.cgi?id=45924 Vincent Hennebert vhenneb...@gmail.com changed: What|Removed |Added CC||levin...@intersystems.com --- Comment #1 from Vincent Hennebert vhenneb...@gmail.com 2012-02-07 07:50:17 UTC --- *** Bug 52597 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45924] New: Improve border painting in collapsing border model
https://issues.apache.org/bugzilla/show_bug.cgi?id=45924 Summary: Improve border painting in collapsing border model Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Created an attachment (id=22658) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=22658) File demonstrating the problem See attached file: the corners adjacent to the cell without borders aren't fully painted, which makes the result not very nice. It would be a nice to have if the borders were fully painted, like in the separate border model (second table). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 36934] - The collapsing border model on an fo:table is currently not supported by FOP
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=36934. 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=36934 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-04-20 03:22 --- Fixed in Trunk, rev. 530727 -- 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.
DO NOT REPLY [Bug 36934] - The collapsing border model on an fo:table is currently not supported by FOP
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=36934. 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=36934 --- Additional Comments From [EMAIL PROTECTED] 2007-04-20 03:30 --- (In reply to comment #3) Fixed in Trunk, rev. 530727 Thank you for fixing this issue. So we can go on with testing. :-) -- 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: Border conditionalities and collapsing-border model, breaks on header/footer
Hi, Thanks for your inputs, Andreas and Jeremias. The whole thing suddenly makes sense when you think in terms of area tree instead of fo tree... Still, I think it's not obvious by reading the spec and I'll probably ask for clarification on [EMAIL PROTECTED] And there is a remaining question raised by Andreas: snip/ [me:] 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? [Andreas:] 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. Interesting point of vue. I think it can be summarized by the attached picture. Jeremias' position corresponds to 1., and I suspect this is the more common understanding. Andreas' is 2., but I'm afraid you'll be alone ;-) Mine's tends to be 3., although I'm ok with 1. If there is no other comment I'll go with 1. 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. Still, nothing prevents users from trying to achieve those weird effects ;-) snip/ - 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... :/ I'm ok with that now :-) Thanks, Vincent
Re: Border conditionalities and collapsing-border model, breaks on header/footer
On Mar 26, 2007, at 11:31, Vincent Hennebert wrote: snip / And there is a remaining question raised by Andreas: snip/ [me:] 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? [Andreas:] 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. Interesting point of vue. I think it can be summarized by the attached picture. Jeremias' position corresponds to 1., and I suspect this is the more common understanding. Andreas' is 2., but I'm afraid you'll be alone ;-) Mine's tends to be 3., although I'm ok with 1. If there is no other comment I'll go with 1. 1. is also fine with me. As I said, it's open for interpretation, and I would agree that option 1. is what the largest part of our audience will expect. In a way, in the majority of use-cases option 2. /almost/ gives the same result as 1. It would only give slightly different results if the column's after- border is different from the before-border. I think you'll have to look hard for cases where people specify different border-specs for the two opposite sides, but as you say: nothing prevents people from achieving weird effects. :-) Cheers, Andreas
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: 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
Status of the collapsing border model
Hi all, Just to let you know that I'd like to finish the implementation of the collapsing border model. I've started to look at the wiki pages, the code and the mail archives but if you have any hint about what are the remaining problems to solve, where to look at in particular, etc., I'm all ears ;-) Thanks, Vincent
Re: Status of the collapsing border model
(Sorry if I miss anything on the list these days. Some of my own mails don't make it back to me from the list and I suspect that other mails don't, either. Not sure what the problem is. Hopefully just a temporary glitch.) My ideas should be visible on the mailing list archives. If they are not apparent, the basic idea is not to allow interaction between headers/footers and the body in terms of border resolution. That may lead to odd-looking borders in some exotic cases but should simplify the implementation a lot. The renderers already only paint half-borders so it's not necessary to change anything in the model. Most of the code necessary is also already there, especially the resolution itself and the painting. Only the right element list construction is missing. There's a synthetic example on the Wiki [1] that shows the problem. Watch out for the exclamation marks in the table. That's where the simplified model would ignore the influence on the header and footer treating it with constant height, thus making it easier to handle with a trade-off in quality. [1] http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder2 Also, don't miss http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel which discusses some important details. Have fun! On 15.11.2006 11:41:12 Vincent Hennebert wrote: Hi all, Just to let you know that I'd like to finish the implementation of the collapsing border model. I've started to look at the wiki pages, the code and the mail archives but if you have any hint about what are the remaining problems to solve, where to look at in particular, etc., I'm all ears ;-) Thanks, Vincent Jeremias Maerki
Re: Status of the collapsing border model
On Nov 15, 2006, at 11:41, Vincent Hennebert wrote: Hi Vincent, Just to let you know that I'd like to finish the implementation of the collapsing border model. I've started to look at the wiki pages, the code and the mail archives but if you have any hint about what are the remaining problems to solve, where to look at in particular, etc., I'm all ears ;-) Collapsing borders again, ay? 8) Well, I still have some ideas up my sleeve for optimization, but AFAIU the basic implementation that Jeremias initially added should work nicely, except for the part that is documented on the Wiki. Unfortunately, I haven't had too much time lately to invest into this, but roughly it comes down to moving a great deal of the collapsing-border-logic to the FOTree. I've had numerous fruitful discussions with Jeremias about this in the past, and I'm still convinced that it would be a good move --performance-wise-- to relocate those parts to the FOTree, and make them accessible to the layoutengine from there. Although it is almost never possible to resolve the borders completely at that stage, since you have no page-breaking context yet, I still feel much for performing as much of the resolving as possible before the layoutengine even gets its hands on those FO nodes. It's not a BIG problem, but still it seems like a waste to have a table with potentially thousands of cells, each one having a CommonBorderPaddingBackground with BorderInfo objects that basically all have the same properties (width / color / style), so my ideas go in the direction of reducing the number of separate BorderInfo instances drastically. If, for example, the table's start-borders would win for all rows, then it seems logical to me that all the cells adjacent to that start-edge actually share that very same BorderInfo instance. Another way to go about that would be to implement BorderInfo as a fly-weight, so that even when there are many different tables with identical border-properties, there is actually only one BorderInfo alive to which all the related FO nodes share a reference... That said, these ideas for improvement can easily wait until we have a fully working implementation to begin with, so go right ahead with this. The community is going to love you for it (if you still needed motivation ;) ) Cheers, Andreas
Re: Indent Inheritance and Collapsing Border Model
Both proposed changes are now implemented. I'm not sure if I got everything right WRT the indent behaviour. I guess I'll have to wait for feedback from those people who wanted that feature in the first place. http://svn.apache.org/viewcvs?rev=354763view=rev http://svn.apache.org/viewcvs?rev=354075view=rev On 01.12.2005 12:53:56 Jeremias Maerki wrote: Hey gang, There are two issues I'd like to discuss. They come from feedback from customers: The first concerns indent inheritance which I documented in [1]. It turns out that most commercial implementations decided to deliberately break indent inheritance to work around the expectations of inexperienced XSL-FO users. This obviously breaks the specification and it creates an interoperability issue. This becomes an issue, especially since I know a few companies that would like switch from commercial implementations back to Apache FOP now that it's more usable now. I've asked the XSL WG in [2] on their updated opinion about the issue. There are arguments in both directions. So what I'd like to do is implement the alternative behaviour as a configurable option in the FO tree. The default would still be what the specification describes (see [1]), but users would be able to set a switch that would make FOP reset start-indent and end-indent to zero in cases where in the area tree a reference area boundary would be crossed (block-containers and table-cell, mainly). [1] http://wiki.apache.org/xmlgraphics-fop/IndentInheritance [2] http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0024.html The second issue is about the collapsing border model. Currently, having an fo:table with no explicit border-collapse=separate results in a warning message in the log as well as frequent exceptions due to the fact that this border model not completely implemented. I would like to modify the FO tree in a way that a table always reports being in separate border model mode. The other idea would have been to change the default but I don't particularly like that approach because it breaks the spec. Obviously, this is only a temporary measure until the collapsing border model becomes usable. I was recently thinking about doing a scaled-down implementation which ignores the tricky interactions between headers/footers and the table-body. But my priorities here are not particularly high, so it might be some time until I get to this. Any objections? Comments? Thanks, Jeremias Maerki Jeremias Maerki
Re: Indent Inheritance and Collapsing Border Model
On Dec 1, 2005, at 12:53, Jeremias Maerki wrote: Hi, There are two issues I'd like to discuss. They come from feedback from customers: The first concerns indent inheritance which I documented in [1]. snip / +1 for making this configurable. [1] http://wiki.apache.org/xmlgraphics-fop/IndentInheritance [2] http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/ 0024.html The second issue is about the collapsing border model. Currently, having an fo:table with no explicit border-collapse=separate results in a warning message in the log as well as frequent exceptions due to the fact that this border model not completely implemented. I would like to modify the FO tree in a way that a table always reports being in separate border model mode. Easiest way, I guess, would be to expand the already existing test in fo.flow.Table.bind()... Weird that this wasn't already being done. I must have read over that bit a hundred times, and never wondered about it, but indeed, it's almost like saying: Not implemented, and now we're going to prove it to you by just continuing as if it were... Who knows, maybe you're lucky. :-) +1 Cheers, Andreas
Indent Inheritance and Collapsing Border Model
Hey gang, There are two issues I'd like to discuss. They come from feedback from customers: The first concerns indent inheritance which I documented in [1]. It turns out that most commercial implementations decided to deliberately break indent inheritance to work around the expectations of inexperienced XSL-FO users. This obviously breaks the specification and it creates an interoperability issue. This becomes an issue, especially since I know a few companies that would like switch from commercial implementations back to Apache FOP now that it's more usable now. I've asked the XSL WG in [2] on their updated opinion about the issue. There are arguments in both directions. So what I'd like to do is implement the alternative behaviour as a configurable option in the FO tree. The default would still be what the specification describes (see [1]), but users would be able to set a switch that would make FOP reset start-indent and end-indent to zero in cases where in the area tree a reference area boundary would be crossed (block-containers and table-cell, mainly). [1] http://wiki.apache.org/xmlgraphics-fop/IndentInheritance [2] http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0024.html The second issue is about the collapsing border model. Currently, having an fo:table with no explicit border-collapse=separate results in a warning message in the log as well as frequent exceptions due to the fact that this border model not completely implemented. I would like to modify the FO tree in a way that a table always reports being in separate border model mode. The other idea would have been to change the default but I don't particularly like that approach because it breaks the spec. Obviously, this is only a temporary measure until the collapsing border model becomes usable. I was recently thinking about doing a scaled-down implementation which ignores the tricky interactions between headers/footers and the table-body. But my priorities here are not particularly high, so it might be some time until I get to this. Any objections? Comments? Thanks, Jeremias Maerki
Re: Indent Inheritance and Collapsing Border Model
Jeremias Maerki wrote: The first concerns indent inheritance [...] So what I'd like to do is implement the alternative behaviour as a configurable option in the FO tree. The default would still be what the specification describes (see [1]), but users would be able to set a switch that would make FOP reset start-indent and end-indent to zero in cases where in the area tree a reference area boundary would be crossed (block-containers and table-cell, mainly). I agree with the need to provide users what they expect, but I did not understand where this switch will be: in the configuration file (+1) or in the document itself as an extension property / element (not so enthusiastic about that)? In the first case the file would be correct, only its rendering will be deliberately wrong: the user is aware that he is requiring a non-standard rendering *to the formatter*. In the second the document itself would require a non-standard rendering, which only our implementation will provide; in other words, it seems to me that this solution would give the impression that the file itself is enough to achieve the expected result, while it is not. Or maybe you were thinking of something else? The second issue is about the collapsing border model. Currently, having an fo:table with no explicit border-collapse=separate results in a warning message in the log as well as frequent exceptions due to the fact that this border model not completely implemented. I would like to modify the FO tree in a way that a table always reports being in separate border model mode. The other idea would have been to change the default but I don't particularly like that approach because it breaks the spec. Obviously, this is only a temporary measure until the collapsing border model becomes usable. I agree with you, I prefer the first option. Regards Luca
Re: Indent Inheritance and Collapsing Border Model
On 01.12.2005 13:30:05 Luca Furini wrote: Jeremias Maerki wrote: The first concerns indent inheritance [...] So what I'd like to do is implement the alternative behaviour as a configurable option in the FO tree. The default would still be what the specification describes (see [1]), but users would be able to set a switch that would make FOP reset start-indent and end-indent to zero in cases where in the area tree a reference area boundary would be crossed (block-containers and table-cell, mainly). I agree with the need to provide users what they expect, but I did not understand where this switch will be: I did not say. in the configuration file (+1) or in the document itself as an extension property / element (not so enthusiastic about that)? In the first case the file would be correct, only its rendering will be deliberately wrong: the user is aware that he is requiring a non-standard rendering *to the formatter*. In the second the document itself would require a non-standard rendering, which only our implementation will provide; in other words, it seems to me that this solution would give the impression that the file itself is enough to achieve the expected result, while it is not. Or maybe you were thinking of something else? No. The second idea would kill the effect of the change. Someone would still have to modify a stylesheet to make it work with FOP. That is not the idea. I assume it will be good enough to control the option via the user agent and indirectly through the configuration file. The second issue is about the collapsing border model. Currently, having an fo:table with no explicit border-collapse=separate results in a warning message in the log as well as frequent exceptions due to the fact that this border model not completely implemented. I would like to modify the FO tree in a way that a table always reports being in separate border model mode. The other idea would have been to change the default but I don't particularly like that approach because it breaks the spec. Obviously, this is only a temporary measure until the collapsing border model becomes usable. I agree with you, I prefer the first option. Thanks for your feedback. Jeremias Maerki
DO NOT REPLY [Bug 36934] New: - The collapsing border model on an fo:table is currently not supported by FOP
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=36934. 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=36934 Summary: The collapsing border model on an fo:table is currently not supported by FOP Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: blocker Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] We committed to test latest FOP from SVN, but actually *every* FO file we want to render ends up in the following message, and no PDF output is created: The collapsing border model on an fo:table is currently not supported by FOP So it seems the lack of this 'feature' blocks us from beeing any further help to the project. :-( -- 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.
DO NOT REPLY [Bug 36934] - The collapsing border model on an fo:table is currently not supported by FOP
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=36934. 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=36934 --- Additional Comments From [EMAIL PROTECTED] 2005-10-05 15:04 --- Which project? Yours or ours? :-) FOP 0.20.5 doesn't fully support the collapsing border model, either. It just pretends it does. The borders are simply painted on top of each other. FOP Trunk doesn't do any such ugly hacks right now. Apart from the warning message you got, what did the output look like? Unusable? Does any committer have a good overview of what exactly works on tables in 0.20.5? Currently, the compliance page suggests that 0.20.5 work much better than FOP Trunk WRT table support which is probably not the case. -- 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: Collapsing border model
Thanks everyone for helping me with this. On 05.05.2005 20:43:58 Simon Pepping wrote: Jeremias, At first sight I agree with Andreas' interpretation in his reply to this message, which I think is the same as your original interpretation. Thinking on, however, I see that there may be a problem with spanned cells. Is that what you are aiming at? Yes, exactly. The cell level, means the level of the spanned cell. This suggests indeed that each side of a spanned cell must be treated as a whole. However, the spec says precisely: If the value of the border-collapse property is collapse or collapse-with-precedence the border is determined, for each segment, at the cell level. Yes, but it's the cell level part that made think twice. I now interpret the each segment part in the way that each segment has to be taken to get at the candidates for a non-segmented cell border. and If the value of the border-collapse trait is collapse, the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the most eye catching border style... At the moment I'm not sure what to think. There are parts of this sentence that let me run on one direction, others let me run in the opposite direction. Moreover, the term 'cell level' is rather vague, and certainly not the same as 'per cell'. That seems to mean that the determination is done per segment indeed, which agrees with your original interpretation. Note that the spec does not define the notion of a segment, nor does the CSS2 spec. But I take it to mean the side of a grid unit. Let's hope so. Your Wiki example shows a result that is probably undesirable, a spanned cell with vastly different border segments. But apparently the spec does not protect the user from specifying such a border arrangement. ...if the original interpretation was correct. Probably it is not possible to define resolution of collapsing border specifications per cell. Consider the following example: ++++ |||| |||| |||| |||| ++---+++ || | || | || | || | ++-+ On the border between rows 1 and 2 each segment is part of two cell borders. Conflicting border specifications can only be resolved per segment, not per cell. Actually, I think it could but the implications are dreadful. Actually, so far this is the one reason in all this that urges me to believe that the original interpretation was indeed correct. Note also this remark in the spec (6.7.3 fo:table) about the background of spanned cells: A cell that is spanned may have a different background in each of the grid units it occupies. This is somewhat similar to the spec allowing different segments on a side of a spanned cell. But that's because you have backgrounds on various levels (rows, columns, column groups, row groups). If you specify the background on a spanned cell it fills all the occupying grid units. You have no means to directly specify a background (at least on cell level) for each of the occupying grid unit. Again, thanks for helping me here. I guess it's best to just leave it like it is right now. It's a lot better than nothing even if the interpretation turns out to be wrong at one point. It also leaves the whole thing simpler. These are, after all, only nits but with a big impact on the complexity. And BTW, a XEP trial version matches more or less my original interpretation even though I found some diffences on start and end borders. Jeremias Maerki
RE: Collapsing border model
-Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] Hi Simon, At first sight I agree with Andreas' interpretation in his reply to this message, which I think is the same as your original interpretation. Thinking on, however, I see that there may be a problem with spanned cells. Is that what you are aiming at? Aah, yes! I knew there was something I was overlooking... The cell level, means the level of the spanned cell. This suggests indeed that each side of a spanned cell must be treated as a whole. However, the spec says precisely: If the value of the border-collapse property is collapse or collapse-with-precedence the border is determined, for each segment, Indeed, and as you point out below --and I also recall from reading the CSS2 spec-- that segment is actually meant to be the 'intersection between a row and a column', such that a row- and column-spanning cell can have different borders and backgrounds for each of the grid-units it occupies. snip / Moreover, the term 'cell level' is rather vague, and certainly not the same as 'per cell'. That seems to mean that the determination is done per segment indeed, which agrees with your original interpretation. Note that the spec does not define the notion of a segment, nor does the CSS2 spec. But I take it to mean the side of a grid unit. Your Wiki example shows a result that is probably undesirable, a spanned cell with vastly different border segments. But apparently the spec does not protect the user from specifying such a border arrangement. Probably it is not possible to define resolution of collapsing border specifications per cell. Consider the following example: ++++ |||| |||| |||| |||| ++---+++ || | || | || | || | ++-+ On the border between rows 1 and 2 each segment is part of two cell borders. Conflicting border specifications can only be resolved per segment, not per cell. Yes and no. Ultimately this problem always poses itself, even in very basic table-grids, for the first cell's after-border, you might have to wait until the before-border for the first cell below it is known... (to be able to fully and correctly resolve the after-borders for the cells in one row, we need the before-border info for the cells in the next row as well) The only thing that seems quite impossible (to me, maybe in error) is that there would be different borders on two sides of the same gridline. In Jeremias' example this would mean that IF the entire before-border of the spanning cell has to be the thick red border, THEN this border-style would also be applicable to the after-border of *both* cells immediately above. (and suddenly I think I see what Jeremias meant by 'ending up taking the after-border of the cell to the right...' in his OP) OTOH, as Jeremias just pointed out in his reply, IF borders are specified at the cell-level, and the cell spans multiple columns/rows, then that border would be a candidate for _all_ the relevant segments --not only the first grid-unit it occupies. If it is dominant over all the others you would end up with a uniform border on all segments. Cheers, Andreas
Re: Collapsing border model
Jeremias, At first sight I agree with Andreas' interpretation in his reply to this message, which I think is the same as your original interpretation. Thinking on, however, I see that there may be a problem with spanned cells. Is that what you are aiming at? The cell level, means the level of the spanned cell. This suggests indeed that each side of a spanned cell must be treated as a whole. However, the spec says precisely: If the value of the border-collapse property is collapse or collapse-with-precedence the border is determined, for each segment, at the cell level. and If the value of the border-collapse trait is collapse, the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the most eye catching border style... Moreover, the term 'cell level' is rather vague, and certainly not the same as 'per cell'. That seems to mean that the determination is done per segment indeed, which agrees with your original interpretation. Note that the spec does not define the notion of a segment, nor does the CSS2 spec. But I take it to mean the side of a grid unit. Your Wiki example shows a result that is probably undesirable, a spanned cell with vastly different border segments. But apparently the spec does not protect the user from specifying such a border arrangement. Probably it is not possible to define resolution of collapsing border specifications per cell. Consider the following example: ++++ |||| |||| |||| |||| ++---+++ || | || | || | || | ++-+ On the border between rows 1 and 2 each segment is part of two cell borders. Conflicting border specifications can only be resolved per segment, not per cell. Note also this remark in the spec (6.7.3 fo:table) about the background of spanned cells: A cell that is spanned may have a different background in each of the grid units it occupies. This is somewhat similar to the spec allowing different segments on a side of a spanned cell. Regards, Simon On Tue, May 03, 2005 at 03:14:50PM +0200, Jeremias Maerki wrote: I've just realized I probably made a big mistake interpreting collapsing border model. While going through the specs to reread everything about the outer table border I carefully reread the following passages: XSL-FO 1.0, 6.7.2, Trait Derivation: If the value of the border-collapse property is collapse or collapse-with-precedence the border is determined, for each segment, at the cell level. So far I've based everything on being determined, for each segment, at the segment level as it seems. I even had the part about cell level highlighted in my print-out and still got it wrong. Damn me! But I think I know why I got it wrong: XSL-FO 1.0, 6.7.10, Trait Derivation: If the value of the border-collapse trait is collapse, the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the most eye catching border style... Obviously sounded too much like a per-segment thing. Under the new light, this means a totally different thing. Looking at my (buggy) example [1] this means that the segment where the arrow points should actually be the same broad red border as the one next to it on the right side. -- Simon Pepping home page: http://www.leverkruid.nl
Re: Collapsing border model
As I have proven a few times now I'm not without flaws. :-) That's where we need peer-review. Thanks for looking into this. On 03.05.2005 21:03:49 Simon Pepping wrote: I am afraid I just followed your interpretation. I will try to read the spec more independently and more critically. Jeremias Maerki
RE: Collapsing border model
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] I've attached the picture and an FO file I wrote today to mimic that picture. Apologies. Damn *me* now for not having tried this with a decent browser... of course IE will let you down. More feedback probably tomorrow. Cheers, Andreas
Collapsing border model
I've just realized I probably made a big mistake interpreting collapsing border model. While going through the specs to reread everything about the outer table border I carefully reread the following passages: XSL-FO 1.0, 6.7.2, Trait Derivation: If the value of the border-collapse property is collapse or collapse-with-precedence the border is determined, for each segment, at the cell level. So far I've based everything on being determined, for each segment, at the segment level as it seems. I even had the part about cell level highlighted in my print-out and still got it wrong. Damn me! But I think I know why I got it wrong: XSL-FO 1.0, 6.7.10, Trait Derivation: If the value of the border-collapse trait is collapse, the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the most eye catching border style... Obviously sounded too much like a per-segment thing. Under the new light, this means a totally different thing. Looking at my (buggy) example [1] this means that the segment where the arrow points should actually be the same broad red border as the one next to it on the right side. That also means that it's making the whole border resolution a lot more complicated. If you started with the upper left cell and tried to determine the after border you can end up taking the after border specification from the cell on the right side of the cell. I'll have to think about how to implement this in an efficient way, first. But before I turn everything upside-down again, can please someone confirm that I was really wrong before and got it right now? Thanks a lot. [1] http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel Jeremias Maerki PS: Can someone please beat me?
RE: Collapsing border model
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi, snip / BTW: Am I the only one who has trouble viewing the pictures on the wiki page? (It seems to be the only one with which I have problems. The other table-related pages show up nicely...) That also means that it's making the whole border resolution a lot more complicated. If you started with the upper left cell and tried to determine the after border you can end up taking the after border specification from the cell on the right side of the cell. Are you talking about what our current implementation *would* end up taking as after border, or what *should* be taken as after border according to the spec? In the latter case, if you mean 'start/end', I'm game, but I don't see how the 'after' border of the first cell to the right of a given cell could influence the 'after' border of that cell... If the border is determined, for each segment, at the cell level that seems to mean a decision at the cell level between: - table - body (header / footer) - column - row - neighbouring cells * start ~ border-end of first cell to the left * end ~ border-start of first cell to the right * before ~ border-after of first cell above * after ~ border-before of first cell below - the cell itself for each of the border segments: start - before - end - after One optimistic note: all of the above options can't be an option at the same time for one and the same cell... and the decision between row borders and table borders, for instance, could already be resolved at row level, such that, when the borders are determined at cell level, the cell only needs to query the row, column and neighbouring cells (not reach back up to the body and table). But before I turn everything upside-down again, can please someone confirm that I was really wrong before and got it right now? Thanks a lot. If I could only see the images... Cheers, Andreas
Re: Collapsing border model
I've attached the picture and an FO file I wrote today to mimic that picture. BTW, the pictures worked fine for me the whole day. They are all here: http://people.apache.org/~jeremias/fop/ Alternatively, if you log into cvs.apache.org you can cd into /x1/home/jeremias/public_html/fop to get them. On 03.05.2005 19:40:39 Andreas L. Delmelle wrote: -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi, snip / BTW: Am I the only one who has trouble viewing the pictures on the wiki page? (It seems to be the only one with which I have problems. The other table-related pages show up nicely...) That also means that it's making the whole border resolution a lot more complicated. If you started with the upper left cell and tried to determine the after border you can end up taking the after border specification from the cell on the right side of the cell. Are you talking about what our current implementation *would* end up taking as after border, or what *should* be taken as after border according to the spec? *should* :-( In the latter case, if you mean 'start/end', I'm game, but I don't see how the 'after' border of the first cell to the right of a given cell could influence the 'after' border of that cell... If the border is determined, for each segment, at the cell level that seems to mean a decision at the cell level between: - table - body (header / footer) - column - row - neighbouring cells * start ~ border-end of first cell to the left * end ~ border-start of first cell to the right * before ~ border-after of first cell above * after ~ border-before of first cell below - the cell itself for each of the border segments: start - before - end - after One optimistic note: all of the above options can't be an option at the same time for one and the same cell... and the decision between row borders and table borders, for instance, could already be resolved at row level, such that, when the borders are determined at cell level, the cell only needs to query the row, column and neighbouring cells (not reach back up to the body and table). Got to think that through first. It might speed things up a little. But before I turn everything upside-down again, can please someone confirm that I was really wrong before and got it right now? Thanks a lot. If I could only see the images... Cheers, Andreas Jeremias Maerki attachment: border-collapse5.png table-border-special2.fo Description: Binary data
Re: Collapsing border model
I am afraid I just followed your interpretation. I will try to read the spec more independently and more critically. Regards, Simon On Tue, May 03, 2005 at 03:14:50PM +0200, Jeremias Maerki wrote: I've just realized I probably made a big mistake interpreting collapsing border model. While going through the specs to reread everything about the outer table border I carefully reread the following passages: XSL-FO 1.0, 6.7.2, Trait Derivation: If the value of the border-collapse property is collapse or collapse-with-precedence the border is determined, for each segment, at the cell level. So far I've based everything on being determined, for each segment, at the segment level as it seems. I even had the part about cell level highlighted in my print-out and still got it wrong. Damn me! But I think I know why I got it wrong: XSL-FO 1.0, 6.7.10, Trait Derivation: If the value of the border-collapse trait is collapse, the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the most eye catching border style... Obviously sounded too much like a per-segment thing. Under the new light, this means a totally different thing. Looking at my (buggy) example [1] this means that the segment where the arrow points should actually be the same broad red border as the one next to it on the right side. That also means that it's making the whole border resolution a lot more complicated. If you started with the upper left cell and tried to determine the after border you can end up taking the after border specification from the cell on the right side of the cell. I'll have to think about how to implement this in an efficient way, first. But before I turn everything upside-down again, can please someone confirm that I was really wrong before and got it right now? Thanks a lot. [1] http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel Jeremias Maerki PS: Can someone please beat me? -- Simon Pepping home page: http://www.leverkruid.nl
Re: Collapsing border model
Jeremias Maerki wrote: PS: Can someone please beat me? Stick, riding crop, whip, rope, chain or plain old bare knuckles? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/
Re: Collapsing border model
Whatever helps. Thanks! On 04.05.2005 04:14:51 Peter B. West wrote: Jeremias Maerki wrote: PS: Can someone please beat me? Stick, riding crop, whip, rope, chain or plain old bare knuckles? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ http://folio.bkbits.net/ Jeremias Maerki
