xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Cell border rendering error (thicker) with number-column-spanned
Date Sun, 04 Nov 2012 08:38:18 GMT
Hi Reeve,
the reason for the change was to support line styles other than "solid",
"dashed" and "dotted" and the collapsing border model on tables. 0.20.5
painted simple lines, resulting in rectangles that effectively
overlapped (potentially producing ugly side-effects themselves). During
the redesign this was changed to using clip paths to cut the lines to
the exact shape that we need. Notes at [1] show why the current model
was chosen. Over time, it has come up a number of times (this isn't the
first time) that anti-aliassing features in various PDF viewers cause
suboptimal results (on screen only, NEVER in print because there is no
anti-aliassing there) with FOP's current approach.

To fix the problem and still preserve the current feature-richness,
there will need to be improvements on the way borders are painted, but
they will not be easy to implement:

The painting of the border grid of a table has to be changed to
group the painting of border segments together. The IFRenderer would
have to be extended with an optimizer of some sorts that can try (!) to
combine the various grid segments to larger combined structures, ex.
longer lines of the same color. That may even have an influence on the
structure of the area tree. There's also a relationship to the z-index
feature (grouping, buffering and ordering of painting operations).
Different line thicknesses may effectively get in the way of that

Ideally, a table with a simple black grid would be painted with just the
minimal set of lines (without clip paths). That would basically
guarantee no side-effects. But that is only possible for the simple
cases. More complex cases require the "tricks" we use here to paint the
border segments and that may easily lead to the unwanted visual
artifacts we're seeing today. So, I don't think there is a silver bullet.
There's room for optimization but not without an influence on the code
complexity. And all that just because some PDF viewers produce different
results for two lines with the same thickness. OTOH, it has the
potential to produce slightly smaller output files.

Anti-aliassing's a bitch that's great for text but only produces issues
with vector graphics.

I do remember extensive discussions on border painting during 2003/2004
that effectively showed the complexity of getting border painting "right".

[1] http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel

Jeremias Maerki

On 04.11.2012 05:16:10 reevev wrote:
> Hi,
> Thanks for providing the sample.  I agree that this illustrates that the
> various PDF viewers are not doing the right thing with the line thickness
> and I'm not disagreeing with this point.  However the fact remains that fop
> 0.20.5 output the borders in a method that the PDF viewers displayed
> correctly and newer versions of fop don't produce the desired output.
> By changing to fop 1.0 (or 1.1) we now are seeing output that isn't rendered
> correctly in the industry standard PDF viewer, as well as other common PDF
> viewers, and this is why I say the bug is with FOP.  It may be technically
> correct output, but if it isn't displayed correctly anywhere it is besides
> the point.
> Is there somewhere I can find out more on why the border rendering was
> changed?  I'm guessing there was a reason it was changed.  If I wanted to
> change the source so it rendered the old way it would probably create
> different issues that I'm not aware of.
> Thanks,
> Reeve.
> --
> View this message in context: http://apache-fop.1065347.n5.nabble.com/Cell-border-rendering-error-thicker-with-number-column-spanned-tp17999p37244.html
> Sent from the FOP - Users mailing list archive at Nabble.com.

To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message