tom sgouros <[EMAIL PROTECTED]> 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
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Hyperlatex-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hyperlatex-users
