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 optimization. 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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
