Forum › Bugs

Weirdness with <clipPath> on SVG referenced via url(#clipPathID)

silverRocket
Hi there

I'm wondering why my PDF will not render correctly when I have an SVG using <clipPath> that is correctly in the <defs>, and then referenced via <g style="clip-path: url(#clipPathReference)">

I *think* I'm doing things according to documentation, but the PDF does not match what is seen with the web browser (instead of an SVG with a clip path provided, the SVG does not render / is perhaps clipped with incorrect dimensions?).

All browsers see/render "withClip" version correctly (change the .src file to .html and drag/drop it on to your browser)

Without the clip-path style, things render correctly, but I need the clip!

Thanks!
  1. withClip.html.src‎ 86.7 kB ‎
    HTML source. Go nuts!
  2. withClip.pdf‎ 109.7 kB ‎
    HTML renders properly, Prince does not
  3. withoutClip.pdf‎ 109.6 kB ‎
    HTML and PDF render the same
silverRocket
Here is what *should* be rendered by prince (captured view of Chrome)
  1. withClip_viaBrowser‎ 43.7 kB ‎
    I'd like to see THIS :)
mikeday
This is due to a limitation of Prince when it comes to handling clipPath elements containing multiple paths, something that PDF doesn't natively support.

We may be able to fix this limitation in a future release, but for now the simplest workaround would be to remove one of the paths, as they appear to be identical.
silverRocket
Thank you Mike!

Indeed I didn't even *see* the duplicated <path> within the <clipPath>. Thank you for your eyes!!
mikeday
Latest builds of Prince now try to handle multiple clip paths by combining them, using a transparency mask, or if worst comes to worst by rendering the image multiple times, once for each path.