Problem: Table cells with background-color attribute specified may damage borders for rounding table cells. Solution: Borders now added over all other cell content. Limitation: PDF only. Technical background: All data concerning table cell borders and background SVG graphics now collecting during usual table generation. At this time there are no borders generated. If table generated successfully the all borders being collected at the time of table content generation will made over (in separate pass).
Created attachment 8947 [details] This is patch for FOP 0.20.5 to solve problem with borders inside table cells with background color specified. For PDF only.
Please submit an actual CVS-generated patch as defined here: http://cocoon.apache.org/2.1/howto/howto-patch.html Full source code is not helpful for us, as we can't see the changes made. Note we are not making many changes to our 0.20.5 maintenance branch--especially those involving significant functionality changes. So it may take awhile before we get to it, or we may just be interested in ensuring the problem does not occur in our future 1.0 version. It would be also helpful for you to attach an extremely simple FO that shows the problem, as well as the output PDF from that FO. Thanks, Glen
*** Bug 29759 has been marked as a duplicate of this bug. ***
Created attachment 11925 [details] Namchaninov's patch in regular diff format
Created attachment 11926 [details] Simple test case
Created attachment 11927 [details] 800% fragment view in Acrobat Reader of pdf generated by 20.5
Created attachment 11929 [details] 800% fragment view in Acrobat Reader generated with 20.5 patched by Namchaninov
I can confirm that bug really manifests itself in 20.5 I can confirm that patched fop generates a better pdf for my sample FO
This Problem is actually two Problems: 1. Borders have to be rendered after backgrounds. Namchaninov's Patch takes care of that. 2. Cell backgrounds are being rendered (0.5pt in every direction) larger than they should, bleeding into and overlapping borders of other cells. This happens because the background is at long last rendered in PDF as a filled rectangle WITH a border in the same color - which I guess to be 1pt wide. Bad function in PrintRenderer: protected void addFilledRect(int x, int y, int w, int h, PDFPathPaint fill) { addRect(x, y, w, h, fill, fill); } My quick'n extraordinary dirty fix is to change the addRect-function in PDFRenderer like this: if (stroke== fill) addFilledRect(x, y, w, h, fill); else { blah..blah.. Hope this helps someone
I hereby confess that I've been wrong about Namchinov's patch. It produces horrible results, see sample bellow. This patch shouldn't be applied by anyone.
Created attachment 12618 [details] Horrible results of Namchinov's patch
Okay, now I've got my own variant of remedy. My own patch. IMO the problem is that rectangles that should methematically be areas startx < x < startx + w starty < y < starty + w are painted as rectangles with borders. This makes them wider and taller then they should be. They start to paint over borders that do not belong to them. I have (hopefully) fixed this for PDF, SVG and AWT renderers. My patch also deletes some unused methods and IMO makes the code a bit cleaner. IMO 0.20.6 should be. It should take as a mantra: we won't struggle to introduce new features. It shouldn't try to fix difficult to fix bugs. It should go for low-hanging fruit. Little code change that will improve user experience. I modestlty consider that this patch should be part of it.
Created attachment 12680 [details] Fix table cells with background not rendered okay for PDF, SVG and AWT renderers.
The issue of borders being painted as rectangles instead of lines has been fixed for PDF in CVS HEAD code. The 0.20.x code is frozen and patches against are unlikely to be applied.
Fixed in FOP 0.94 and probably since 2004-09-10 (see Chris comment)
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed