Fading of horizontal lines is impossible?

Question

The path fading option in TikZ is obviously not working for horizontal lines. For plotting constant functions as well as for drawing a line between two points. Making them slightly tilted solves the problem. Is this a know error and is there some way to work around?

Here is a minimal example

\documentclass[a4paper,11pt]{article}
\usepackage{tikz,pgfplots}
\usetikzlibrary{fadings}
\begin{document}
\begin{tikzpicture}[>=stealth]
  \begin{axis}[scale=3, domain=-1.1:6.5, xmin=-1, xmax=6.5,ymax=2, axis lines=none]

   \addplot+[no marks,red,dashed,domain=-1:6.5] {0.7};
   \addplot+[no marks,red,dashed,domain=-1:6.5,path fading=east] {0.8}; %not working


   \draw[red,dashed,path fading=east] (axis cs:-1,0.9) -- (axis cs:6.5,0.9); %not working
   \draw[red,dashed,path fading=east] (axis cs:-1,0.9) -- (axis cs:6.5,1);

  \end{axis}

\end{tikzpicture}
\end{document}

Welcome to TeX.SX. Usually, we don't put a greeting or a "thank you" in our posts. While this might seem strange at first, it is not a sign of lack of politeness, but rather part of our trying to keep everything very concise. Accepting and upvoting answers is the preferred way here to say "thank you" to users who helped you. — Claudio Fiandrino, Mar 11 '13 at 18:35
My suspicion is that the bounding box of a horizontal path has zero height (this is backed up by the error message of PGF trying to divide 1 by 0.0). Tilting it fixes that. Perhaps something that added a bit of height to the bounding box would fix this (but I don't know how to do that). — Andrew Stacey, Mar 11 '13 at 18:37
@AndrewStacey: You could just append ++(0,1pt) to the \addplot command and to the path. — Jake, Mar 11 '13 at 18:48
@Jake That would be a hack! Better would be to fix the fading so that it used a minimal sized bounding box. Or use a key that put in a box of the right size via an append after command type argument. — Andrew Stacey, Mar 11 '13 at 20:19

score 14 · Accepted Answer · answered Mar 12 '13 at 00:07

Well, it's possible but you have to cooperate with TikZ. What you are doing is essentially trying to fit the fading which is defined on a nonzero area to a zero area with (nonzero width). The fadings library offers another key fit fading with which you can turn off the fading resizing accordingly to the path but this will fade regardless of your path length. Or you can simply use what Jake has suggested, namely extending the bounding box a little to get a nonzero area without actually drawing something. Or you need to define your own custom fading which should be tricky in this case. Anyway here is an example with the first two options:

\documentclass[a4paper,11pt]{article}
\usepackage{pgfplots}
\pgfplotsset{compat=1.7}
\usetikzlibrary{fadings}

\begin{document}
\begin{tikzpicture}[>=stealth]
  \begin{axis}[domain=-1.1:6.5, xmin=-1, xmax=6.5,ymax=2, axis lines=none]

   \addplot+[no marks,red,dashed,domain=-1:6.5] {0.7};
   \addplot+[no marks,red,dashed,domain=-1:6.5,path fading=east,fit fading=false] {0.8}; %now working


   \draw[red,dashed,path fading=east] (axis cs:-1,0.9) -- (axis cs:6.5,0.9) ++(0,1pt); %now working
   \draw[red,dashed,path fading=east] (axis cs:-1,0.9) -- (axis cs:6.5,1);

  \end{axis}

\end{tikzpicture}
\end{document}

enter image description here

Note that you are not actually fading a path, you are seeing the underlying fading through the path hence zero height means you can't see anything if you try to fit. That's what TikZ is complaining about.

On my system, when I compile this answer without any modifications, I do not see any fading on either of the four lines, they are all solid. Is this answer still valid? Or am I missing something on my system that causes the fading to break? — lanoxx, Nov 07 '16 at 14:23
ouch, I was using evince on Ubuntu (its the standard Gnome PDF viewer), using Okular from KDE solves the issue. Too bad, I really like evince. — lanoxx, Nov 07 '16 at 15:10

brac37 · Answer 2 · 2015-07-11T20:05:40.900

3

There are several ways to extend the path in such a way that its bounding box gets a positive surface.

\draw[red,dashed,path fading=east] (axis cs:-1,0.9) -- (axis cs:6.5,0.9) 
++(0,1pt); % extend the path with a degenerate subpath (see Percusse)

\draw[red,dashed,path fading=east] (axis cs:-1,0.9) -- (axis cs:6.5,0.9) 
++(0,1pt) -- ++(0,0); % extend the path with a zero length subpath

\draw[red,dashed,path fading=east] (axis cs:-1,0.9) -- (axis cs:6.5,0.9) 
-- ++(0,1pt); % extend the subpath

The best solution is to use a degenerate subpath (only one coordinate, Percusse), although it seems a bit of a hack. But the other two only work with the default fading.

For the other two solutions, the path extension must be on the faded edge of the bounding box, (here the right side/east side) so that you cannot see them. With extremely thick lines, you will however see glitches, but it is probably better to use rectangles in that case.

Another solution is to draw a faded white rectangle over the line, and a white line over the rectangle's faded border to remove glitches. If this is possible, then this is even a better solution, because it works for evince as well.

edited Jul 11 '15 at 20:05

answered Jul 07 '15 at 23:38

brac37

133

1

I understand from your profile description that you don't like the action taken on your previous post. Note that the action was not done by moderators, but by the community. Also, as mentioned before, this is not a forum... so even though you want to comment on things "for the greater good", that can't be done really by new users. You have to gain trust (through reputation, at least 50) in the community before your contributions can be added through comments. That's just the way it is... – Werner Jul 07 '15 at 23:45
...how is your code snippet different from percusse's answer? Please explain, since I don't know TikZ that well... and it looks like you're saying basically the same. – Werner Jul 07 '15 at 23:46
2

@Werner. The -- before the ++. -- extends the subpath, no -- starts a new one. ++ means realtive to the previous point. If they would not have been moderators in my definition, then -3 instead of 0 in front would have been the effect, not this. – brac37 Jul 07 '15 at 23:50
@brac37 Thank you. I stared at this for ages trying to see the difference. It may seem obvious to you but it would be really helpful if you could integrate this comment into your post. I don't really know anything about subpaths, even though I use TikZ, and I didn't know what I was looking for. It is easy to miss what seems obvious to somebody with more expert eyes. If you could explain what starts a subpath and what you've done to avoid that, it would be a lot clearer. – cfr Jul 07 '15 at 23:57
Also, I am not really sure what the remark about round caps is referring to. Your code doesn't use that and neither does percusse's as far as I can tell. Are you saying that a similar issue with rendering subpaths happens when round caps are used for line endings, and that's why you think not starting a new subpath unnecessarily here is safer? – cfr Jul 08 '15 at 00:00
@cfr: Indeed, round line caps are half circle disks, so a circle is to be expected with only one coordinate, I think. – brac37 Jul 08 '15 at 00:05
@Werner. Maybe you are right about that it is more suited as a comment. A reason for keeping it like this is that the fading of the path extension is really new. Percusse's path extension is already not drawn because a subpath with one coordinate is not drawn (I do not expect renderers to produce glitches here). – brac37 Jul 08 '15 at 00:16
1

You shouldn't add -- . The use of -- is not relevant here. Because the fading works like a fill. It should not be drawn because it does not belong to the path. That's why I omitted it and that's why I voted to delete because this is going in the wrong direction with the identical message that I have in my answer. This needs to be a comment if you prefer -- – percusse Jul 08 '15 at 00:59
1

The bounding box is also updated without --. That's why my answer works. Hence I don't know what you are trying to convey here. – percusse Jul 08 '15 at 01:04
I still don't understand the point about round caps. It is true that \draw [line cap=round] (0,0) -- (0,0); will draw a circle. But I don't see what that has to do with the issue here. I'm still confused. – cfr Jul 08 '15 at 01:48
@cfr. Correct, as opposed to \draw [line cap=round] (0,0); and useful for e.g. human icons for which the head should have the same width as the body part (which I have made). – brac37 Jul 08 '15 at 16:09
It is not a bit of hack. What you are doing is the actual hack hiding behind the fading. It will fail with certain fadings. Plus you can also remove the whole thing (try removing --++(0,1pt). Can you explain why it is working? I recommend the source code. – percusse Jul 08 '15 at 16:43
I'm lost. No idea what making human icons has to do with the current topic. – cfr Jul 08 '15 at 17:30
As I pointed out, subpaths with only one coordinate are not dealt with as zero length paths, which I think is buggy behavior. So there is a reason to avoid such paths. Everyone can choose for himself whether it is a good reason. – brac37 Jul 08 '15 at 18:54
That's not correct. First, that's not even a subpath it is a pen moveto so there is no zero path length. Moreover, these are context dependent statements. Here as I demonstrated you can even remove the extras. There is no buggy behavior; this was an issue earlier. You are basically repeating your mistaken answer and claiming that this is a point of view. – percusse Jul 09 '15 at 15:32
@percusse: -- is a monadic operator, not a seperator, which makes the line cap issue expected behavior. If you had written that long ago, then I would not have answered repeated questions (with basically repeated answers). – brac37 Jul 11 '15 at 20:26

Fading of horizontal lines is impossible?

2 Answers2

Linked