On 05.08.2014 17:56, Luis Bernardo wrote:
On 8/5/14, 8:44 AM, Vincent Hennebert wrote:
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
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
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

So, if I were to tackle this, I think my first approach would be
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.

Yes, I am aware that the renderer does not know about tables. But in
fact that knowledge is not even necessary. Just knowing the segments
would be enough and this would be done at page level, not table level
(which can in any case span more than one page). And the algorithm would
be a lot simpler than one might image, specially because the segments
are drawn in some "natural" order which would make the algorithm fast
too (something like this: is the next segment horizontal? yes; do we
have a segment with the same Y? yes; do the ends touch? yes; is the
thickness and color the same? yes; them merge them to make just one
segment; next segment...).

But if we want to do the same in PostScript then I agree that doing this
before we get to the renderer is better.

Thanks for all your suggestions, this is very helpful. I like the simplicity of your approach Luis, but I'll try to handle it in the LMs so that PostScripts benefits too and we have a greater control over which shapes get merged.
I'll report in the next view days as soon as I can start with this job.

One more thing: Is there a recommended way to evaluate the performance impact of my changes? I searched in the mailing lists and found only Jeremia's "FOP Benchmarks" ( http://www.jeremias-maerki.ch/download/fop/FOP%20Benchmarks.zip ). I'll give it a try, please let me know, if there is some other way.


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
that analyzes the segments and outputs a set of lines (and their
that correspond to the sides of the rows and columns. Then draw those
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
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
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
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
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
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
to do some work or research on this issue and wants to share his
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