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 30146] - postscript - table - border-collapse-separate
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=30146. 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=30146 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-04-20 03:23 --- Fixed in Trunk. -- 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: SpaceHandling[Break]Position, associated LayoutManager and AreaAdditionUtil
On 19.04.2007 11:24:20 Vincent Hennebert wrote:
Hi,
Is there any reason why SpaceHandling[Break]Position elements created by
SpaceResolver don't have any LayoutManager associated to them?
I guess I didn't see the need to have one when I implemented this.
As a result, in AreaAdditionUtil.addAreas, if the first Position element
is a SpaceHandling[Break]Position, then the position list is not
iterated over to add areas for childLMs.
l.103: while ((childLM = childPosIter.getNextChildLM()) != null) {
The loop isn't entered if the first position is a
SpaceHandling[Break]Position, as it will return a null LayoutManager.
Or are such positions supposed to never be first in the list?
See block_space-before_space-after_2.xml. There, it is first in the
element list.
If you have a case where this has a negative side-effect, then, of
course, a test case has to be written and the problem adressed. It
simply wasn't an issue so far.
Jeremias Maerki
Re: svn commit: r530727 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fo/flow/Table.java status.xml
Hi Jeremias, Jeremias Maerki a écrit : Great news, Vincent! Good stuff! Thanks! Although there is still some work to do. Of course, I had to try it out immediately and it looks promising. Still, I've got a few points for you to look into: - Please reenable the two test cases for border collapse. That'll help catching regressions. You may need to add additional tests (including checks for the element lists) to cover all possibilities . Actually the first test still doesn't pass because of a forced height set on a row which is handled wrongly. The fixed height is directly applied to the BPDs of the contained cells, instead of substracting the cells' border-top/bottom widths. This is independent of the collapsing model. The second test needs to be completed, I'll do that in the next days, along with creating additional testcases. - table_border-collapse_collapse_1.xml shows a little flaw in border painting. Check out the lower left edge of cell 1. Looks like a special situation where the normal border logic that I've come up with in 2005 doesn't look so nice. I mean, inside the table there's little that you can do to avoid such an effect, I think, but in the table's outer border the border could be fully painted if the adjacent cell doesn't have a border, it could be improved. Probably low priority as it is a special situation (and other implementations look much worse than FOP now). But maybe it's good to keep an eye on it. Hmmm, indeed. I agree with you that this is of low priority, because I really don't expect such a case to occur often in real life. Moreover, this belongs to the border-painting part and I don't feel like starting to look at it now. While we're speaking of border-painting, FOP's behavior doesn't match Firefox's one. At the grid intersections, Firefox draws the biggest border, instead of drawing each of the four borders merging at the intersection point (hope I'm clear, can't find the words). We can see an illustration of that in the CSS2 spec: http://www.w3.org/TR/REC-CSS2/tables.html#border-conflict-resolution I don't think either of the two behaviors is required by the spec. But I think both might be desirable as they let achieve different effects. The Firefox one will cause... interesting problems to occur as a cell's content may be encroached upon by a border which doesn't play in the resolution of that cell's borders! - There seems to be a bug with the area generation when you have padding and a background. The cell's content area doesn't declare any padding and the horizontal position doesn't take padding into account. Therefore content is vertically displaced and the cell background doesn't cover the padding. See attached FO (the supposedly black cells at the bottom). Should be easy to fix. Thanks for spotting that, I've committed a fix. Testcases pending. Cheers, Vincent
