The problem is that \newlength is a "global" command; so after the first figure, \plotwidth is defined. However, \setlength is a "local" command, so its setting is forgotten after the figure environment and reset to the initial value which is 0pt.
In general \newlength should be a preamble command. You can set it globally to a sentinel value, say -1000pt,
\newlength{\plotwidth}
\setlength{\plotwidth}{-1000pt}
and then check against this value with
\ifdim\plotwidth=-1000pt
in fig.tex. If you say
\begin{figure}
\setlength{\plotwidth}{100pt}
\input{fig}
then the code in fig.tex will know that \plotwidth has been set.
Let's work out an example. Your fig.tex file contains
\ifdim\plotwidth=-1000pt
\setlength{\figwidth}{0.9\linewidth}
\else
\setlength{\figwidth}{\plotwidth}
\fi
\includegraphics[width=\figwidth]{somefigure}
(the parameter will be \figwidth instead of \linewidth, for greater flexibility).
Your main file can be
\documentclass{article}
\newlength{\plotwidth}
\setlength{\plotwidth}{-1000pt}
\newlength{\figwidth}
\begin{document}
\begin{figure}
\input{fig.tex}
\caption{Test (this figure is 90\% of the line width)}
\end{figure}
\begin{figure}
\setlength{\plotwidth}{100pt}
\input{fig.tex}
\caption{Test (this figure is 100pt wide)}
\end{figure}
\end{document}
I agree with the guys in the other forums - the issue is likely that the text file is in the wrong encoding - but I disagree with their solution. Depending on your operative system, I'll suggest two different solutions:
Under Linux
First a disclaimer: I use Ubuntu, and the exact commands might be slightly different under other distributions. The general idea is the same, however, so you should be able to iron out any cranks with the help of Google...
Confirming the diagnosis
To confirm that encoding is in fact the issue, cdto the folder where your files reside, and do
$ file *
That should give you an output like the following (etc for more files):
example.tex: LaTeX 2e document, UTF-8 text
input.txt: ISO-8859 text
If the text file is listed as ISO-8859 (or something similar), or in fact anything other than "UTF-8 text", then encoding is your problem.
Fixing the problem
To convert ISO-8859 (a.k.a. "Latin 1") to UTF-8, you can use the following command
$ iconv -f latin1 -t utf8 input.txt > input.utf8.txt
iconv is an encoding conversion utility. -f latin1 and -t utf8 are arguments to iconv that tell the program which encoding the file is currently in, and which encoding you want it in. For a complete list of possible encoding names, do iconv --list. The last argument is the file name of the input file (i.e. the one in the "wrong" encoding). iconv writes the file, in the new encoding, to stdout, so we redirect the output into a new file (don't use the same file name - you'll overwrite your file with an empty one).
Under Windows
Confirming the diagnosis
My standard way of confirming encoding problems under windows is to open the file in Notepad and select Save as... - then there's a little dropdownlist that lets you choose the encoding of the file - if you don't change it, it states the current encoding of the file. Usually, files that I find problematic when using UTF-8 turn out to be saved in ANSI, which is Microsoft's own encoding (and quite similar to ASCII).
If encoding is your problem, this dropdownlist shows something other than "UTF-8".
Fixing the problem
To fix it, simply select UTF-8 in the dropdownlist, (optionally) select a new file name for your input file, and hit Save.
Notepad converts the file intelligently, but if you experience problems you can (usually) simply reverse the process to get back the file you started with, and try something else.
Best Answer
The following is written to accord to Mac OS Xs' FHS implementation. This is principally valid for any UNIX-like OS. Pdflatex allows you to specify complete paths:
Under Unix-Like systems you may even use shell(bash) variables in you paths:
or common abbreviations
(note: using
\stringhere to tell latex to pass the character to shell instead of taking the "meaning")Of course you may also specify relative paths. This means of course you need to know what your active path is. For pdflatex this is most commonly the path (or directory) were yout main document lies (which is given pdflatex as an argument).
This will tell pdflatex to use
some_filewhich is located in the active dir. (If not an error will be raised.)Will do exactly the same, while
will tell pdflatex to use
some_filewhich lies in the parent folder (one level above.)So one might ask why? Well under common OSs like UNIX or Windows the dot representations are in charge, so that
.represents the current/active folder and..the parent. Therefore../../will represent a folder two levels above (the parent of the parent). This is possible, since the directory tree only knows one parent a a certain level. So 'going up' is all the same on any level.