I looked at this in the past. I think I understand what you mean by shapes and solid lines but I don't think the issue is that. The problem, as I understood it, is caused by the fact we draw many segments now where before there was only one. So if you have a row with 5 cells the top and bottom sides of the row are drawn as 5 segments (one for each cell) where before (with 0.20.5) there was just one segment spanning the 5 cells. The issue is really with the viewer, not with FOP, but it does make sense to come up with a workaround.

So, if I were to tackle this, I think my first approach would be something similar to your suggestion 2. I would do it on the PDF renderer, since this only affects PDF (or we only care about that), and it would go like this: when you get the commands to draw the sides of the cells do not draw them and instead collect them. Once you you are done with the table, use an algorithm that analyzes the segments and outputs a set of lines (and their positions) that correspond to the sides of the rows and columns. Then draw those lines, that form a grid, in one go. The fact that you use shapes or lines for that should not make a difference.

On 8/4/14, 4:38 PM, Matthias Reischenbacher wrote:

I've gotten the request from multiple of my clients to look into the border display issues caused by anti aliasing in PDF viewers. I'm aware that printing the PDF documents generated by FOP is never the issue, but when viewing, there definitely is (I know that anti aliasing can be disabled in Adobe Acrobat, but I can't control my users environment). Since viewing PDF files on electric devices is getting more and more important, I think it's worth to have a new look on this issue. Digging around in the FOP mailing lists, I've discovered that PDF viewers don't like that table borders are rendered with shapes instead of lines. I'm aware that shapes are used for supporting all border styles of the xsl-fo spec. The thing is that 99% of my clients use only solid lines, so it is important to improve the display quality here. AFAIK there are two possible ways to achieve this:

1. Fallback to the old (0.20.5) table border rendering code, if only solid lines are used inside a table.

2. Algorithm for merging shapes if width, color and style match.

Are you aware of any other ways to improve this? I'll start to investigate both approaches in the next view days, so I can't say much about the viability and expected dev time yet. Perhaps some of you has already started to do some work or research on this issue and wants to share his experience. Personally I'm more inclined towards approach #2, but I have a limited time budget to achieve this, so if #2 involves a lot of work I'd go for #1.

Best regards,

Reply via email to