CSWAP scaling problems
tigerjack opened this issue · 4 comments
Describe the bug
Width of line in CSWAP gates does not scale properly.
To Reproduce
\documentclass[tikz]{standalone}
\usepackage[compat=0.6]{yquant}
\begin{document}
\begin{tikzpicture}[scale=.3\textwidth]
\begin{yquant}
qubit {} a[3];
swap (a[0], a[1]) | a[2];
\end{yquant}
\end{tikzpicture}
\end{document}
Expected output
Width of lines should scale in the same way, while the image clearly shows that the line connecting the two X has a different size with respect to the line stemming from the control qubit.
Screenshots
First of all, note that your code is invalid: The scale parameter expects a positive, dimensionless number, not a dimension (so scale=0.3 would be ok). If you want to "scale" something to have a certain width in the end, this is not directly possible. TeX does not know the native width of the object beforehand, so it also does not know which scaling factor to apply. But you could put the content in a box, then scale the box output appropriately afterwards, or just use the adjustbox package, which does this for you.
Second, you write that the width of lines should scale in the same way. I disagree with this. Since yquant is built on top of TikZ, it should behave in the same way as TikZ does. And in TikZ, line widths are never affected by the scale parameter, it is the expected behavior that the lines are not larger. You must explicitly change the line width in order to affect lines. (Note that for example also the register lines to not scale.)
That said, there is a bug in the SWAP gate with respect to scaling, which is in the path clipping command. Since it is not possible to clip against lines, I instead simulated the lines of the X by a complicated path that traces the X shape. However, since this is now a combination of path moving and line to commands, it is affected by the scaling that is currently active, contrary to the lines. That's why in the middle, a larger and larger white region will appear - the clipping grows while the drawing stays the same. I'll have a look into this so that also the clipping does not change any more. Maybe that's also what you meant, I just wasn't able to figure out what your actual problem according to your description.
@projekter In trying to provide a MWE, I simplified too much. I include the example I provide in a main file using the includestandalone package, to which I provide a scaling factor. So, supposing the file in the original post is called cswap.tex (without the scale parameter), I have another file with the following code
\documentclass{report}
\usepackage[compat=0.6]{yquant}
\usepackage{standalone}
\begin{document}
\begin{figure}[!htbp]
\includestandalone[width=\textwidth]{cswap}
\end{figure}
\end{document}
which produces something like this
for which you can clearly see the difference in width between the different vertical lines of the CSWAP. The next image provides another example, taken from a different file, showing the same issue.
As a final note, I tried to put the new code of yquant-shapes.tex in the yquant.sty file I have, between the BEGIN_FOLD and END_FOLD associated to it, but the issue persist. Not sure if it's the right way to test it, though.
I cannot reproduce this. Also, I fail to see that there is any width difference in the lines on the images that you posted. All the lines have exactly the same width, however, their color appears to be different (the vertical line between the SWAPs seems to be much more black, the others are more of a gray). I would guess that this is an issue with your PDF renderer, perhaps due to some badly implemented LCD filtering. When I render the example, it looks exactly as expected:
Tested with Sumatra (mupdf), Acrobat, Foxit, and TeXstudio (poppler). There are not many more PDF engines available, what do you use and on which operating system? Does the problem persist in all zoom levels? What about smoothing settings in your reader?
Indeed, there is a "reasonable" explanation for this (wrong) behavior: You use a multi-register gate together with controls. This leads to yquant drawing both a control line from the very first to the very last register involved, using every control line, and a multi-register line between the individual groups of multi-registers involved (here, there is only one group, which consists of the first two registers), using every multi line. Usually, the latter is a wiggly line to make this distinction clear (this is non-standard, but also not done usually, as there would be no way to discriminate multiple multi-registers with a control if all lines had the same style) - but since the established notation for swap is a straight line, this is changed for this particular gate. The lines are drawn on top of each other, and they have the exact same width, vertical position and color, so a proper renderer should just overpaint without any issues.
You can verify what I wrote by altering your code for the circuit slightly:
\begin{tikzpicture}
\begin{yquant}
qubit {} a[3];
[every control line/.append style={red}, every multi line/.append style={blue, densely dotted}]
swap (a[0], a[1]) | a[2];
\end{yquant}
\end{tikzpicture}Now you can see how the two lines exactly overlap, with the control line in the background:
Regarding your final note, no, my fix was related to the issue that I described above. There is nothing I can do to fix broken renderers.
I just provided another commit that should address the issue of drawing (partially) the same thing twice. Now, yquant checks whether a control line is present and avoids drawing the multi-register line in the particular case when it is identical to the control line. It is still possible for the use to provide a custom style for the multi-register line in order to get it back.
@projekter I was thinking of a reader rendering issue as well, but I opened the issue because the problem was present on zathura, mupdf, Okular, PDFXchange and Firefox. Yeah, indeed the line seems to be fine when you are at a normal level, but if you zoom out a bit you can clearly see the differences. Ok, maybe the MWE of before is not enough, so I will provide another one
\documentclass[tikz]{standalone}
\usepackage[compat=0.6]{yquant}
\begin{document}
\begin{tikzpicture}
\begin{yquant}
qubit {} a[10];
qubit {} b[10];
qubit {} c[1];
\foreach \idx in {0, ..., 9} {
\yquant
swap (a[\idx], b[\idx]) | c[0];
}
\end{yquant}
\end{tikzpicture}
\end{document}
I think the difference is visible even at normal zoom levels now, on your browser or PDF reader.
Anyway, the latest fix you provided worked, it works like a charm now at any zoom level. Thanks a lot :)