After I opened an assignment whose name included an underscore character, I heard from my students about difficulty in getting a hardcopy. I found that "protect_underbar" would prevent a major error during the LaTeX processing.
Is there something similar to cope with LaTeX handling names for graphics files, e.g., \{ image( "1.2.3.png" \} seems to signal LaTeX that the filetype is "2.3.png" about which it is ignorant. I recognize that renaming things (e.g., "c1s2p3.png") is one type of fix, but I wonder whether I have other options (e.g., at the price of making the \{ image() \} call be more complicated). Note: WeBWorK seems to have no difficulty locating and displaying such graphics for live display --- the difficulty arise upon trying to produce hardcopy.
Hi Dick,
This is an issue with TeX and how WeBWorK implements it. Maybe we can make the implementation a little more robust. here is some info from http://www.tex.ac.uk/cgi-bin/texfaq2html?label=grffilenames
“Modern” graphics file names
TeX was designed in a world where file names were very simple indeed, typically strictly limited both in character set and length. In modern systems, such restrictions have largely disappeared, which leaves TeX rather at odds with its environment. Particular problems arise with spaces in file names, but things like multiple period characters can seriously confuse the graphics package.
The specification of TeX leaves some leeway for distributions to adopt file access appropriate to their operating system, but this hasn’t got us very far. Many modern distributions allow you to specify a file name as "file name.tex" (for example), which helps somewhat, but while this allows us to say
\input "foo bar.tex"
the analogous usage
\includegraphics{"gappy graphics.eps"}
using “ordinary” LaTeX causes confusion in xdvi and dvips, even though it works at compilation time. Sadly, even within such quotes, multiple dots give \includegraphics difficulties. Note that
\includegraphics{"gappy graphics.pdf"}
works in a similar version of PDFTeX.
If you’re using the graphics package, the grffile package will help. The package offers several options, the simplest of which are multidot (allowing more than one dot in a file name) and space (allowing space in a file name). The space option requires that you’re running on a sufficiently recent version of PDFTeX, in PDF mode — and even then it won’t work for MetaPost files, which are read as TeX input, and therefore use the standard input mechanism).
grffile.sty
Distributed as part of macros/latex/contrib/oberdiek (or browse the directory); catalogue entry
This is an issue with TeX and how WeBWorK implements it. Maybe we can make the implementation a little more robust. here is some info from http://www.tex.ac.uk/cgi-bin/texfaq2html?label=grffilenames
“Modern” graphics file names
TeX was designed in a world where file names were very simple indeed, typically strictly limited both in character set and length. In modern systems, such restrictions have largely disappeared, which leaves TeX rather at odds with its environment. Particular problems arise with spaces in file names, but things like multiple period characters can seriously confuse the graphics package.
The specification of TeX leaves some leeway for distributions to adopt file access appropriate to their operating system, but this hasn’t got us very far. Many modern distributions allow you to specify a file name as "file name.tex" (for example), which helps somewhat, but while this allows us to say
\input "foo bar.tex"
the analogous usage
\includegraphics{"gappy graphics.eps"}
using “ordinary” LaTeX causes confusion in xdvi and dvips, even though it works at compilation time. Sadly, even within such quotes, multiple dots give \includegraphics difficulties. Note that
\includegraphics{"gappy graphics.pdf"}
works in a similar version of PDFTeX.
If you’re using the graphics package, the grffile package will help. The package offers several options, the simplest of which are multidot (allowing more than one dot in a file name) and space (allowing space in a file name). The space option requires that you’re running on a sufficiently recent version of PDFTeX, in PDF mode — and even then it won’t work for MetaPost files, which are read as TeX input, and therefore use the standard input mechanism).
grffile.sty
Distributed as part of macros/latex/contrib/oberdiek (or browse the directory); catalogue entry
Thanks, Arnie, for the reference. It appears that even if I managed to tweak my system to handle a multi-dot graphics file, such accommodation is not apt to be available in most WeBWorK installations. The most portable practice for WeBWorK authors would seem to require avoiding multi-dot names for graphics files.
Hi Dick,
If you find a really robust solution, we could incorporate it into the WeBWorK distribution. However since I don't think this is too much of a problem (it's easy to avoid periods in file names), we should be very cautious that we don't create other problems (e.g. in the installation process) with a "solution".
Arnie
If you find a really robust solution, we could incorporate it into the WeBWorK distribution. However since I don't think this is too much of a problem (it's easy to avoid periods in file names), we should be very cautious that we don't create other problems (e.g. in the installation process) with a "solution".
Arnie