# Pattern in \addplot inherits dashed option from previous \draw

I want to fill the area between two curves with a pattern, let's say horizontal line. Since I want some other dashed lines below these curves, I use \draw[dashed] and then \addplot[pattern=horizontal lines] (twice).

I notice that the area is filled with two different pattern options, dashed and solid and the cause is the previous \draw. In fact, if I remove the \draw line or if I put it later in the code, the area is filled right.

To solve this, I can put an "invisible" line before using \addplot, but I'd like to know if is there any "more elegant" solution and why \addplot inherits the options, what is the cause.

Here's an example of the code

\documentclass{article}

\usepackage{pgf,pgfsys,pgffor}
\usepackage{pgfplots}
\usepackage{pgfplotstable}
\usepackage{tikz}
\usetikzlibrary{intersections,arrows,positioning,patterns}

\begin{document}

\begin{tikzpicture}
\pgfplotstablesort\coordinates{
0 0
1 0
1 1
}
\pgfplotstablesort\coordinatesTwo{
0 0
0 1
1 1
}
\begin{axis}[ xmin=0, xmax=1, ymin=0, ymax=1]
\draw[gray,loosely dashed,line width=.8pt] (axis description cs:0,0) -- (axis description cs:1,1);
%NOTICE THE DIFFERENCE WITH AND WITHOUT THE FOLLOWING LINE UNCOMMENTED
%\draw[line width=1pt, solid] (axis description cs:0,0) -- (axis description cs:0,0.01);
\addplot[line width=1pt,no markers,solid,  pattern=horizontal lines, draw=blue] table \coordinates;
\addplot[line width=1pt,no markers,solid,  pattern=horizontal lines, draw=blue] table \coordinatesTwo;
\end{axis}
\end{tikzpicture}

\end{document}

EDIT: the question can be reduced as follows, with the same effects:

\documentclass{article}

\usepackage{pgf,pgfsys,pgffor}
\usepackage{tikz}
\usetikzlibrary{intersections,arrows,positioning,patterns}

\begin{document}

\begin{tikzpicture}[x=8cm,y=8cm]
\draw[gray,loosely dashed,line width=.8pt] (0,0) -- (1,1);
%NOTICE THE DIFFERENCE WITH AND WITHOUT THE FOLLOWING LINE UNCOMMENTED
%\draw[line width=1pt, solid] (0,0) -- (0,0.01);
\draw[line width=1pt,no markers,solid,  pattern=horizontal lines, draw=blue] plot coordinates {(0,0) (1,0) (1,1)};
\draw[line width=1pt,no markers,solid,  pattern=horizontal lines, draw=blue] plot coordinates {(0,0) (0,1) (1,1)};
\end{tikzpicture}

\end{document}
• I don't see the behaviour you describe, the shading is correct in both cases. Do you have the newest versions of the packages? – Andrew Swann May 24 '13 at 8:06
• @AndrewSwann Sure, Miktex and all packages are upgraded. Can you confirm that you see horizontal lines in both the triangle (0,0)--(0,1)--(1,1) and in (0,0)--(1,0)--(1,1)? in the latter, I have DASHED horizontal lines. – Nicola May 24 '13 at 21:48
• I notice that if you compile with pdflatex, you get it all right. Instead, if you compile with latex and convert in ps and them in pdf, you get my issue. I'm not really familiar with the compiling and post process, any ideas? – Nicola May 24 '13 at 22:07
• I can reproduce the issue: pdflatex produces horizontal lines whereas latex P && dvips -o P.ps P.dvi && ps2pdf P.ps P.pdf produces dashed horizontal lines. I can also confirm that the dvips route works well with your second solid \draw. – Christian Feuersänger May 25 '13 at 10:54
• Interestingly, the .ps file of the dvips route works well; i.e. the postscript file renders correctly when viewed with gs. Maybe an error in ps2pdf? Note that pstopdf fails to convert the file at all... – Christian Feuersänger May 25 '13 at 10:55

I found that

(a) acrobat reader does NOT have the problem

(b) convert from the imagemagick suite does NOT produce the problem

(c) ghostscript's gv P.pdf does NOT produce the problem

(d) xpdf HAS the problem

(e) evince HAS the problem

I conclude that it is a viewer problem; perhaps a bug in libpoppler?

Perhaps the question is too localized.

• You're right Christian, it is probably a viewer problem. I use Sumatra to view the output, and it shows me the dashed lines. On the contrary, if I open the pdf output with acrobat reader all is fine. – Nicola May 25 '13 at 14:44
• I have a similar problem and tested the second example. The original output is shown correctly with texstudio, gv and evince. However, optimizing the output with ghostscript's gs -o main_opt.pdf -sDEVICE=pdfwrite main.pdf produces a wrong output with texstudio and evince. – Stefan Sep 20 '16 at 8:30