mgieseki / dvisvgm

A fast DVI, EPS, and PDF to SVG converter
https://dvisvgm.de
GNU General Public License v3.0
303 stars 31 forks source link

`transparency group=knockout` does not work #272

Open tobiasBora opened 1 month ago

tobiasBora commented 1 month ago

I'd love to be able to use the awesome transparency group=knockout feature, that allows us to paint in transparent color to reveal the underlying image. For instance (taken from the doc):

\documentclass[dvisvgm]{minimal}

\usepackage{tikz}

\begin{document}
\begin{tikzpicture}
  \shade [left color=red,right color=blue] (-2,-1) rectangle (2,1);
  \begin{scope}[transparency group=knockout]
    \fill[white] (-1.9,-.9) rectangle (1.9,.9);
    \node[opacity=0,font=\fontencoding{T1}\fontfamily{ptm}\fontsize{45}{45}\bfseries]{Ti\emph{k}Z};
  \end{scope}
\end{tikzpicture}
\end{document}

is supposed to write TikZ in a rainbow-like fashion. But since this is poorly supported by pdf viewers/printers, I wanted to export to svg directly. But running:

$ lualatex --output-format=dvi test
$ dvisvgm test
$ inkscape test.svg

gives me

image

which is not at all the expected result as we cannot read tikz in rainbow like colors, and the huge right margin is also weird.

Thanks a lot for considering this!

mgieseki commented 1 month ago

Unfortunately, I can't help you with this because the dvisvgm backend of TikZ computes all the SVG elements and embeds them into the DVI file using special dvisvgm:raw. So, there's almost nothing to process by dvisvgm.

Here's an excerpt from the DVI file decoded by dviasm:

push:
  xxx: 'dvisvgm:raw <clipPath id="pgfcp1"><path d=" '
  xxx: 'dvisvgm:raw M -56.90549 -28.45274 M -56.90549 -28.45274 L -56.90549 28.45274 L 56.90549 28.45274 L 56.90549 -28.45274 Z M 56.90549 28.45274  '
  xxx: 'dvisvgm:raw "/> </clipPath>{?nl} '
  xxx: 'dvisvgm:raw <g clip-path="url(#pgfcp1)">{?nl} '
  xxx: 'dvisvgm:raw <g transform="matrix(1,0,0,1,0.0,0.0)">{?nl} '
  xxx: 'dvisvgm:raw <g transform="matrix(0.0,1.0,-1.0,0.0,0.0,0.0)">{?nl} '
  xxx: 'dvisvgm:raw <g transform="matrix(1.134,0,0,2.26802,0.0,0.0)">{?nl} '
  xxx: 'dvisvgm:raw  <linearGradient id="pgfsh2" gradientTransform="rotate(90)">{?nl} <stop offset="0.0" stop-color=" #00f "/>{?nl} <stop offset="0.25" stop-color=" #00f "/>{?nl} <stop offset="0.5" stop-color=" #800080 "/>{?nl} <stop offset="0.75" stop-color=" #f00 "/>{?nl} <stop offset="1.0" stop-color=" #f00 "/>{?nl} </linearGradient>{?nl} '
  xxx: 'dvisvgm:raw <g transform="translate(-50.1875,-50.1875)"> '
  xxx: 'dvisvgm:raw <rect width="100.375" height="100.375" style="fill:url(#pgfsh2); stroke:none"/>{?nl} '
  xxx: 'dvisvgm:raw </g> '

The literal SVG fragments are not evaluated and therefore especially don't affect the graphic states of the DVI engine. There are some literal <g transform='translate(...)'>...</g> elements present which tell the user's SVG renderer to move objects around on the canvas. In your example it shifts the text from the right into the rectangle. From dvisvgm's perspective, however, the text is still located at the original position mentioned in the DVI file and therefore the bounding box gets enlarged accordingly.

So, these issues would need to be fixed in the dvisvgm backend of TikZ.

tobiasBora commented 1 month ago

Thanks a lot for your timely answer. I submitted a bug report upstream https://github.com/pgf-tikz/pgf/issues/1349