I'm curious about how I can remove the border from the SVG images in this HTML. When I open the HTML in a browser, there are no borders, but when I turn the HTML into a PDF, there is a thin gray border around each image. I've attached two HTML-PDF pairs that demonstrate the issue. The Graph Report demonstrates the issue, but it's not super annoying. More concerning is the Sparkline Report. I've tried removing all borders from everything using .sparkline * { border: none !important } in the CSS, but to no avail. With the Sparkline Report, I've actually got two borders that I want removed, but I can't get either to go away. In the browser, neither border shows up, and all elements are showing that they are honoring the { border: none !important } declaration.

Any ideas? I am using Prince 12.

1. Graph Report.pdf‎ 195.1 kB
2. Graph Report_1099426_2018_09_28_13_46_41_user_1699.html‎ 283.9 kB
3. Sparkline Report.pdf‎ 51.7 kB
4. Sparkline Report_512399_2018_09_26_15_09_41_user_1699.html‎ 270.6 kB

Would you be able to attach the generated SVG?

The SVG images are embedded in the HTML file using inline <svg> elements. I've isolated and attached one of them, the first image from the Graph Report HTML file.

In case it helps, these SVG images are being generated using FusionCharts Javascript rendering. We generate the HTML, including the <script> necessary to render the SVG. We run it through PhantomJS to evaluate the JS and create the SVG, remove the <script> elements, and then run it through Prince. I would suspect something about that process, but the end result HTML displays fine without the border in a browser but not in a PDF generated by Prince. Maybe a difference in how SVG is being rendered?

1. graph.svg‎ 19.2 kB

I messed with the SVG a little, and it looks like some <rect> elements with a stroke-width="0.000001" attribute are causing the problem. If I replace that attribute with stroke-width="0.000000" everything looks right. I'm not sure what the rationale from FusionCharts is for elements that are supposed to draw an invisible (or imperceptible) line, and I have a workaround now, but it appears that is where the rendering difference lies.

Good work tracking that one down!