On 04/08/14 23:30, Luis Bernardo wrote:
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
The challenge will be to pass the information to the PDF renderer that
we are dealing with a table. Renderers don’t have that information, all
they know is that they are drawing a block with borders all around.
Re-constructing that information is likely to be hard, messy and
error-prone. Best would probably be to handle that in TableLM where all
the information still is available.
There you could have an object that holds a grid, with cells
contributing to it as they are processed. Then you would decide what is
the most common pattern (say, 1pt solid black), reset it on cells (so
that they only keep border information for non-standard borders), and
pass this object to renderers.
BTW, the PostScript renderer might well benefit from that too, as
I remember complaints in the past that the file size was growing too big
due to all the drawing commands generated solely for borders.
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.