Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I am stumped by the following problem. I'm not sure if this is a bug in TikZ, or if I misunderstand the way that lengths work in TeX and in TikZ.

I'd like to define a length called \mywidth, and use it in TikZ pictures in my document. I've tried the following method, which didn't work. Firstly, I added the following in my preamble:

\newlength{\mywidth}
\setlength{\mywidth}{1cm}

Then inside a tikzpicture environment, I try the following code:

\draw (0cm,0cm) to [out=0, in=180] (\mywidth,1cm);

It doesn't work! I get a strange error: Missing \csendname inserted.

However, if I simply type

\draw (0cm,0cm) to [out=0, in=180] (1cm,1cm);

then it does work. What am I doing wrong?

share|improve this question
    
Hi, welcome to TeX.SX. It's always better to add a minimal working example (MWE) that illustrates your problem, so that other people can compile the code for themselves and also implement and test their solutions. See my answer for an example of a MWE. –  Martin Scharrer May 15 '11 at 19:54
1  
Your two \draw lines are identical. Maybe you copied&pasted the second one incorrectly? –  Martin Scharrer May 15 '11 at 19:56
2  
Hi Bruce, welcome to TeX-SX! A minor question: do you need \width (rather, \mywidth as Martin recommends) to be a genuine TeX length? I usually handle this sort of thing with a simple macro: \def\mywidth{1cm}. That works with all of the versions that Martin provides (obviously, the \the\mywidth don't work). There's no need for things that we consider lengths to be the same as what TeX considers lengths. –  Loop Space May 15 '11 at 20:17
    
I agree with @Andrew here and maybe should have mentioned that in my answer. BTW: \def is basically like \newcommand in this case. So the more LaTeX-style way to write it would be \newcommand{\mywidth}{1cm}. –  Martin Scharrer May 15 '11 at 20:21
    
Thanks for informing me about my two \draw lines being identical. I fixed that and I also changed the \width to \mywidth since that wasn't a relevant part of the problem. –  Bruce Bartlett May 15 '11 at 20:24
show 4 more comments

1 Answer 1

up vote 8 down vote accepted

This actually seems to be a bug of the in and out options. It should work like you have it. It does work for the normal -- operator and for to without these options. It seems that in this cases the coordinates are parsed differently. You can work around this by writing \the\width instead. This converts the length into its string representation which avoids this parser issue. See also the question "to path + relative coordinates in TikZ?" which also suffers from similar issues related to the to path operator.

\documentclass{article}

\usepackage{tikz}

\newlength{\mywidth}
\setlength{\mywidth}{1cm}

\begin{document}

\begin{tikzpicture}
    \draw (0cm,0cm) -- (\mywidth,1cm); % Works!
    \draw (0cm,0cm) to (\mywidth,1cm); % Works!
    \draw (0cm,0cm) to [] (\mywidth,1cm); % Works!
    \draw (0cm,0cm) to [in=180] (\mywidth,1cm); % Error
    \draw (0cm,0cm) to [out=0]  (\mywidth,1cm); % Error
    \draw (0cm,0cm) to [out=0, in=180] (\mywidth,1cm); % Error
    \draw (0cm,0cm) to [in=180] (\the\mywidth,1cm); % Works
    \draw (0cm,0cm) to [out=0]  (\the\mywidth,1cm); % Works
    \draw (0cm,0cm) to [out=0, in=180] (\the\mywidth,1cm); % Works
\end{tikzpicture}

\end{document}

If you need a factor like .5 in front of \mywidth you need to write .5*\the\mywidth instead or use \dimexpr: \the\dimexpr.5\mywidth\relax. (The \relax at the end might not be necessary but is there to be on the safe side)


Also note that \width, \height, \depth and \totalheight are often used internally by LaTeX commands to represent the dimension of a processed box and should therefore be better avoided. For example \raisebox{<length>}{<content>} allows you to use them to raise the content relative to its original dimension: \raisebox{.5\height}{Text}

share|improve this answer
    
Thanks a lot. The \draw to operation seems pretty buggy. For instance, \draw (0,0) to[controls = +(1,0) and +(-1,0)] (3,3); doesn't work, but the code \draw (0,0) to[controls = +(0:1) and +(180:1)] (3,3); does. (!) This is causing me some serious problems since I would like to apply style declarations inside the to operator, eg. to[color=blue] but half the time the \draw to[...] doesn't work! –  Bruce Bartlett May 15 '11 at 20:07
1  
@Bruce: Please use backticks to mark inline code: `code`. This case is not a bug, but a limitation: The , are used to separate option=values pairs, so they are not allowed in the option values. You need to wrap the whole value in { } here: \draw (0,0) to[controls = {+(1,0) and +(-1,0)}] (3,3); then it should work. –  Martin Scharrer May 15 '11 at 20:12
1  
If it's a bug can someone please report it? –  Jannis Pohlmann May 15 '11 at 20:21
1  
I would hesitate at calling this a bug. From a little experimentation, this might be to do with expansion. pgfmath tries to expand the coordinates to find numbers on which to compute, and if it ends up with unknown stuff then it assumes that they are node names. Since \mywidth isn't expandable, pgfmath assumes that \mywidth,1cm is a node name. The moral of the story is that you shouldn't confuse TeX lengths with TikZ lengths. Best to stay on the "high level" with pure macros unless you know what you are doing. –  Loop Space May 15 '11 at 20:23
1  
Martin: Ah, okay. More complicated than I thought. Incidentally, the question you linked to in your answer, tex.stackexchange.com/questions/3217/…;, appears to be solved in PGF2.10. I just updated my answer there. –  Loop Space May 15 '11 at 20:36
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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