3

Consider the following LaTeX manuscript featuring a TikZ picture* containing an empty, red-bordered node placed at the picture's origin.

\documentclass{article}
\usepackage{tikz}
\begin{document}
    \tikz \path[draw=red] (0,0) node[draw] {};
\end{document}

When this manuscript is compiled with pdflatex the result is a pdf file with the following picture of a red square, as expected:

The output of pgflatex

However, when the same manuscript is compiled with latex the result is a dvi file with the following picture of a black square:

The output of latex

When the node is replaced by a line segment:

\tikz path[draw=red] (0,0) -- (1,0);

both pdf and dvi look the same, showing a red line segment, as expected:

A red line segment

Why does latex draw a black square?


* This picture was the subject of this post, which may or may not be related to the present question; I suspect that it is, but I don't know for sure, hence the separate question.

  • 1
    try \documentclass{article} \usepackage{tikz} \begin{document} \tikz \path (0,0) node[draw=red] {}; \end{document} (this is more correct code) and see if now appear difference between latex and pdftex – Zarko Aug 6 '17 at 7:44
  • 2
    i just like to point, that the way you write the code is not correct, so appearing colors are accidentally such as you see them (they aren't well defined) ... but let us wait to some latex/tikz guru, what (s)he will say. – Zarko Aug 6 '17 at 7:50
  • 5
    TikZ and DVI doesn't always play well together, see e.g. tex.stackexchange.com/questions/84182 and tex.stackexchange.com/questions/5826. Not sure if this same thing is the cause of the problems here though, I don't know much about the very low level stuff. – Torbjørn T. Aug 6 '17 at 8:07
  • 4
    @Zarko I don't agree. The syntax \path[draw=red] is allowed and should have a well-defined effect on nodes on the path. To me it looks like a bug in one of the driver. – Ulrike Fischer Aug 6 '17 at 13:10
  • 4
    I'm voting to close this question as off-topic because it's a bug in the PGF backend driver for dvi. – Paul Gaborit Aug 6 '17 at 13:17
3

This is basically a bug in the default PGF backend driver for DVI (pgfsys-dvips), and as such, it should be reported using https://sourceforge.net/p/pgf/bugs/.

  • Note that TeXShop (which the OP was using) converts the dvi to pdf, so (as the manual states (section 10.2.1), the pgf driver should be explicitly to pgfsys-dvipdfm.def. This actually doesn't help for TeXShop, but remedies the situation for skim (a Mac specific viewer) when viewing the dvi (it also converts it). So I am not sure if this is a bug in PGF or merely a viewer issue. – Mark Wibrow Aug 7 '17 at 8:29
  • @MarkWibrow All PDF backend drivers are correct. – Paul Gaborit Aug 7 '17 at 8:42
2

as latex/tikz gurus find out your problem is caused by bug, but as workaround until bug will be eliminated you can use my suggestion in the first comment:

\documentclass{article} 
\usepackage{tikz} 
\begin{document} 
\tikz \path (0,0) node[draw=red] {}; 
\end{document}

apparently my claim, that is my code more correct then yours, is wrong. thank to Ulrike Fischer for pointing me to my mistake.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.