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:
Hi,
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,
Matthias
