#241 div/null error by `(270:length)` and a fading line

[schotter]

\begin{tikzpicture}[scale=.6,every node/.style={scale=0.6}]
    \foreach \x in {0,45,...,180} {
        \draw[gray] (0,0) -- (\x:2);
    }

    \draw[gray,path fading=south] (0,0) -- (225:2);
    \draw[gray,path fading=south] (0,0) -- (270:1.5);   % 270 brings up
                                                        % an div/null error
%    \draw[gray,path fading=south] (0,0) -- (269:1.5);   % works as expected
%    \draw[gray,path fading=south] (0,0) -- (269.9:1.5); % no div/null error
%                                                        % but the line is
%                                                        % ultra thin
%    \draw[gray] (0,0) -- (270:1.5);     % works, so the error
%                                        % is related to fading
    \draw[gray,path fading=south] (0,0) -- (315:2);
\end{tikzpicture}

[Till Tantau]

Fixed in the cvs.

[Christian Feuersänger]

Reopening: the issue is not fixed entirely.

\documentclass[a4paper,10pt]{article}
\usepackage[utf8]{inputenc}
\usepackage{tikz}
    \usetikzlibrary{arrows,fadings}
\begin{document}
\begin{tikzpicture}[path fading=south]
    \draw [color=blue,path fading] (1,0) -- (1,1);
    \draw [color=blue,path fading] (-4,0) -- (-4,1);
    \draw [color=blue,path fading] (4,0) -- (4,1);
    \draw [color=blue] (7,0) -- (7,1);

the following item fails:

    \tracingmacros=2 \tracingcommands=2
    \draw [color=blue,path fading] (6,0) -- (6,1);
\end{tikzpicture}
\end{document}

I took a brief look: it calls

\pgfsys@usefading #1#2#3#4#5#6#7->\expandafter \ifx \csname pgfsmaskxform@#1\endcsname \relax \pgferror {Undefined fading '#1'}\else {\expandafter \ifx \csname pgfsmaks@#1\endcsname \relax \pgf@sys@pdf@install@mask {#1}\fi \pgftransformreset \pgftransformcm {#2}{#3}{#4}{#5}{\pgfpoint {#6}{#7}}\csname pgfsmasktrans@#1\endcsname {\pgflowlevelsynccm \pgfsys@invoke {/pgfsmask\csname pgfsmask@#1\endcsname \space gs}}\message {inverting matrix 
(\pgf@pt@aa , \pgf@pt@ab 
 \pgf@pt@ba , \pgf@pt@bb ) shift \the \pgf@pt@x , \the \pgf@pt@y 
}\pgftransforminvert \message {= 
(\pgf@pt@aa , \pgf@pt@ab 
 \pgf@pt@ba , \pgf@pt@bb ) shift\the \pgf@pt@x , \the \pgf@pt@y 
}\pgflowlevelsynccm }\fi 
#1<-south
#2<-0.008
#3<-0.0
#4<-0.0
#5<-0.57716
#6<-170.71646pt
#7<-14.22636pt

and attempts to invert the CM; the debug statement above says

inverting matrix 
(0.008, 0.0
 0.0, 0.57716) shift 170.31519pt, -14.74004pt
! Dimension too large.
<recently read> \pgf@pt@x 

[Till Tantau]

Indeed. I had a look at the code and the trouble is that, indeed, huge numbers arise because the fading is squeezed and this squeezing needs to be undone in the driver if we want to recycle the xforms. This unsqueezing does, indeed, result in huge numbers.

There are two ways around this, both tricky: One can switch to a special calculation mechanism to handle the large numbers, but this may result in huge numbers in the PDF, which may or may not be a problem. The cleaner solution is to (re)create a new xform for each use of a fading, resulting in a larger PDF file and more overhead, but higher precision.

This will be fixed some time in the future, hopefully.

[flying sheep]

I either have a test case or a new bug:

\documentclass{article}

\usepackage{tikz}
\usetikzlibrary{fadings}

\begin{document}

\begin{tikzpicture}

\begin{scope}[shift={(10, 0)}]
\draw[black!40, thick, path fading=south] (0, 0) -- (0, -5);
\end{scope}
\end{tikzpicture}

\end{document}