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.

15
  • 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
    Commented Aug 6, 2017 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
    Commented Aug 6, 2017 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. Commented Aug 6, 2017 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. Commented Aug 6, 2017 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. Commented Aug 6, 2017 at 13:17

2 Answers 2

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/.

2
  • 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. Commented Aug 7, 2017 at 8:29
  • @MarkWibrow All PDF backend drivers are correct. Commented Aug 7, 2017 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .