From: Jay B. <bel...@tr...> - 2004-08-26 04:16:24
|
tom sgouros <to...@as...> writes: > >On Wed, 25 Aug 2004 22:09:12 -0500, Jay Belanger wrote: > >>> Wait a minute. I think I've been asleep. So the change, intended to >>> deal with a warning (not an error), has introduced the possibility of >>> an error in the default case? > >> No; I was terribly unclear. >> No new errors (that I'm aware of) were added; I was responding to >> Ralf's musings about adding other functionality. > > Yes, but there was a warning, when hyperlatex got to the line that > read 'mv file.gif .', and now there's an error when a directory > doesn't exist to store the output file. Right, but there would have been before, too. Given \begin{image}{imagename}, before Hyperlatex would try 1) dvips ... file.dvi -o imagename.ps 2) ps2image ... imagename.ps imagename.png 3) mv imagename.png htmldirectory/imagename.png and 3) would give an error if htmldirectory was "." Now, Hyperlatex will try 1) dvips ... file.dvi -o imagename.ps 2) ps2image ... imagename.ps htmldirectory/imagename.png and there's no need for 3). If the htmldirectory is ".", then what happens now is just like before, without the now unnecessary move. If htmldirectory is something else, then all the new behavior does is (effectively) roll steps 2) and 3) into step 2). In both cases there will be problems if imagename is of the form imagedirectory/name. If ./imagedirectory doesn't exist, both will fail at step 1). If htmldirectory/imagedirectory doesn't exist, then before Hyperlatex would fail at step 3, now it will fail at step 2) (because step 3) has been rolled into step 2)). > Or perhaps I'm missing something. Or maybe I am. > This was only to move files from the source to the html directory, but > it's more or less the same problem you're dealing with. Wouldn't it > be better to have an \imagepath command instead of messing with the > command syntax? Plus that does away with the confusion about what the > directory is supposed to mean. If you want the images in a different directory than the html files, that sounds like a good idea. >> \begin{image}{directory/name} >> ... >> \end{image} >> Hyperlatex couldn't deal with that before and it can't deal with it >> now. > > In this case, it's not really clear what the right behavior should > be. That's the real hurdle. It's not possible from this syntax to > tell what is intended: is this directory where the file comes from or > where it's going? The meaning simply isn't clear, to a person or a > sophisticated text editing program. Since Hyperlatex is creating the image files, I'm not sure how this could indicate where the file is coming from. I've been satisfied with the current behavior (the imagename can't be of the form imagedirectory/name) so I haven't thought about this a whole lot, so I may well be missing something. Jay |