Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

transparency group=knockout does not work #272

Open
tobiasBora opened this issue Jul 10, 2024 · 2 comments
Open

transparency group=knockout does not work #272

tobiasBora opened this issue Jul 10, 2024 · 2 comments
Assignees
Labels
TikZ issue TikZ issue must be fixed upstream

Comments

@tobiasBora
Copy link

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
Copy link
Owner

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
Copy link
Author

Thanks a lot for your timely answer. I submitted a bug report upstream pgf-tikz/pgf#1349

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TikZ issue TikZ issue must be fixed upstream
Projects
None yet
Development

No branches or pull requests

2 participants