Menu
▾
▴
hyperlatex-users
|
From: Ralf H. <ra...@he...> - 2004-08-24 07:55:49
Attachments:
ps2image
hyperlatex.sty
|
Hello,
I had a problem when using
hyperlatex -image
in conjunction with the default \htmldirectory{.}.
hyperlatex produces a file.makeimage with the command
mv file.png .
Of course this results in an error since the file is already there and
cannot be moved to itself.
Yes, it would be possible to convince my Makefile to ignore such an
error, but I think I have another solution. See the modified files in
the attachment.
hyperlatex.sty:
I have modified \endimage to produce a command suitable for the
modified ps2image. So instead of
ps2image -png ... file.ps > file.png
mv file.png .
it will produce
ps2image ... file.ps htmldir/file.png
ps2image:
This script recognises the target filetype from a parameter that ends
in .png or .gif. The extension .ps is always assumed to be the input
filename.
Since the target filename includes the targed directory, an additional
move of the file is unnecessary.
It even seems ps2image is a bit shorter. ;-)
The only problem that remains is the following.
It is now possible to say
\begin{image}{dir/file} ... \end{image}
and the picture file.png (or file.gif) will be generated in the
subdirectory 'dir', but only if 'dir' already exists. There is no code
at the moment, that would generate such a missing directory.
Maybe I could think about putting some extension code into my rhxxname
package, but this will take some more spare time.
Best regards
Ralf
|
|
From: Jay B. <bel...@tr...> - 2004-08-25 13:17:54
|
Ralf HEMMECKE <ra...@he...> writes:
> Hello,
>
> I had a problem when using
>
> hyperlatex -image
>
> in conjunction with the default \htmldirectory{.}.
>
> hyperlatex produces a file.makeimage with the command
>
> mv file.png .
>
> Of course this results in an error since the file is already there and
> cannot be moved to itself.
>
> Yes, it would be possible to convince my Makefile to ignore such an
> error, but I think I have another solution. See the modified files in
> the attachment.
This seems to work pretty well for me.
Would there be any problems with commiting it?
Jay
|
|
From: tom s. <to...@as...> - 2004-08-25 13:45:18
|
>On Wed, 25 Aug 2004 08:17:46 -0500, Jay Belanger wrote: > This seems to work pretty well for me. > Would there be any problems with commiting it? Jay: If you've tested it, go ahead. It sounds like a good idea to me. -tom ------------------------ tomfool at as220 dot org http://sgouros.com http://whatcheer.net |
|
From: Jay B. <bel...@tr...> - 2004-08-25 16:05:55
|
tom sgouros <to...@as...> writes: ... > If you've tested it, go ahead. It sounds like a good idea to me. Okay; it's been committed. Jay |
|
From: Jay B. <bel...@tr...> - 2004-08-25 17:28:54
|
Ralf HEMMECKE <ra...@he...> writes:
...
> The only problem that remains is the following.
> It is now possible to say
>
> \begin{image}{dir/file} ... \end{image}
>
> and the picture file.png (or file.gif) will be generated in the
> subdirectory 'dir', but only if 'dir' already exists. There is no code
> at the moment, that would generate such a missing directory.
It would be easy enough to have ps2image create the necessary
directory, but another problem is that file.ps will be created as
./dir/file.ps. This would occur (in texfile.makeimage) before
ps2image is called, and if htmldirectory isn't ".", then the png file
will be htmldir/dir/file.png. So both directories ./dir and
htmldir/dir would have to exist. It would be nice if file.ps were just
./file.ps, but the ps file name is made by TeX based on the image name
dir/file, and I don't know how to (reasonably) strip off the directory
name in TeX.
For those who haven't looked at the TeX code recently, the TeX code
itself creates a shell script to call dvips and ps2image to create
file.png. The shell script looks roughly like
dvips ... texfile.dvi > \im...@na...
ps2image .... \im...@na... htmldirectory\im...@na...g
The TeX command \image@name is given the value imagename from
\begin{image}{imagename}. So if imagename contains a directory, the
the ps file will be created in that directory relative to ".", but
the png file will be put in that directory relative to htmldirectory.
One possibility is to add the htmldirectory to the ps file name in
TeX, and then, assuming that "hyperlatex texfile" is run before
"hyperlatex -image texfile", have the necessary directories created by
emacs.
(I'm not sure how clear I'm being....)
Jay
|
|
From: tom s. <to...@as...> - 2004-08-25 21:06:19
|
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? I'm not sure that's progress. Wouldn't it have been easier to make the Makefile (the original source of the problem) behave? -tom ------------------------ tomfool at as220 dot org http://sgouros.com http://whatcheer.net |
|
From: Jay B. <bel...@tr...> - 2004-08-26 03:09:32
|
tom sgouros <to...@as...> writes:
> 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.
I don't think that Hyperlatex used to be able to deal with directories
in the image names (I just double checked --- it couldn't), it can't
now, either. My unclear, long-winded message was only meant to say I
didn't know of a good way of dealing with things like
\begin{image}{directory/name}
...
\end{image}
Hyperlatex couldn't deal with that before and it can't deal with it
now.
Next time I'll try to get more sleep before I write.
Or maybe more caffeine....
Jay
|
|
From: tom s. <to...@as...> - 2004-08-26 03:35:38
|
>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. Or perhaps I'm missing
something.
> I don't think that Hyperlatex used to be able to deal with directories
> in the image names (I just double checked --- it couldn't), it can't
> now, either. My unclear, long-winded message was only meant to say I
> didn't know of a good way of dealing with things like
No, it didn't. TeX doesn't do so well here, either. But that's why
packages like psfig.sty have a \psfigurepath command, to specify the
source file. I put this in my siteinit to deal with more-or-less the
same problem when I was making a psfig parallel for hyperlatex:
\HlxEval{
(put 'figpath 'hyperlatex 'hyperlatex-ts-set-figurepath)
(put 'figuremove 'hyperlatex 'hyperlatex-ts-figuremove)
(defvar hyperlatex-ts-figurepath)
(defun hyperlatex-ts-set-figurepath ()
(setq hyperlatex-ts-figurepath
(hyperlatex-parse-required-argument)))
(defun hyperlatex-ts-figuremove ()
(if hyperlatex-final-pass
(let ((file (hyperlatex-parse-required-argument)))
(let ((infile (concat hyperlatex-ts-figurepath "/" file))
(outfile (concat hyperlatex-html-directory "/" file)))
(message "Copying %s to %s" infile outfile)
(copy-file infile outfile t)))))
}
\newcommand{\figureplace}[7][\relax]{
\begin{figure}[#3]
\label{#4}
\begin{center}\xmlattributes{img}{border="0"}
\EmptyP{#7}{\xlink{\htmlimage{#6}}{#7}}{\htmlimage{#6}}
\caption{#2}
\end{center}
\end{figure}
\figuremove{#6}}
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.
> \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.
-tom
------------------------
tomfool at as220 dot org
http://sgouros.com
http://whatcheer.net
|
|
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
|
|
From: Ralf H. <hem...@ri...> - 2004-08-26 10:23:59
|
Hello, maybe I should also say something here.
Jay is right. The modification does not add any functionality that
hyperlatex did not have before.
Hyperlatex cannot deal with directories in filenames. And my suggested
modifications did not mess with that.
>>> \begin{image}{directory/name} ... \end{image} Hyperlatex couldn't
>>> deal with that before and it can't deal with it now.
Well, with hyperlatex-relative-prefix it is easy. Only the line
following ;rhx: has been added to the hyperlatex 2.7 code.
(Of course one has to do this also for hyperlatex-format-gif and
hyperlatex-format-img.)
(defun hyperlatex-format-image ()
(let* ((opt (hyperlatex-parse-optional-argument))
(tags (if opt opt ""))
(resolution (hyperlatex-parse-optional-argument))
(dpi (hyperlatex-parse-optional-argument))
(url (hyperlatex-parse-required-argument)))
;rhx: added the following line
(setq url (concat (hyperlatex-relative-prefix) url))
(delete-region hyperlatex-command-start
(progn (search-forward "\\end{image}") (point)))
(hyperlatex-delete-whitespace)
(hyperlatex-pop-stacks)
(hyperlatex-gen
(format (concat "img src=" hyperlatex-meta-dq "%s."
hyperlatex-imagetype hyperlatex-meta-dq " %s /")
url tags))))
}
If I am not wrong then everything works fine if htmldir is ".".
> It would be easy enough to have ps2image create the necessary
> directory, but another problem is that file.ps will be created as
> ./dir/file.ps.
Well, Jay, you are again right. I did not think of this because my
htmldir is ".". But again, hyperlatex is not supposed to handle things
like \begin{image}{directory/name} ... \end{image}. So at least we have
not introduced a bug that wasn't there before.
> This would occur (in texfile.makeimage) before ps2image is called,
> and if htmldirectory isn't ".", then the png file will be
> htmldir/dir/file.png. So both directories ./dir and htmldir/dir
> would have to exist. It would be nice if file.ps were just
> ./file.ps, but the ps file name is made by TeX based on the image
> name dir/file, and I don't know how to (reasonably) strip off the
> directory name in TeX.
Hmmm, I cannot think of a quick solution to strip off the directory part
with latex, but it should work somehow.
But let me ask you about a change. At the moment I have to write some
html page that has several places where some math occurs. Having learnt
about \begin{image}{file}..\end{image}, I now simply put the math there
and let hyperlatex generate a .png for the html document. What bothers
me most is that I have to give a file name for every image environment
and additionally these filenames have to be unique over the document.
In the \endimage code in hyperlatex.sty appears \the\@imagecount. So why
not replace the line
\jobname.dvi\space>\space\im...@na...^^J%
by
\jobname.dvi\space>\space\jobname\the\@imagecount.ps^^J%
and the same with
ps2image\space -res\space \image@resolution\space \im...@na...%
replaced by
ps2image\space -res\space \image@resolution\space
\jobname\the\@imagecount.ps%
I would then even add code to ps2image to remove the .ps file.
Who would ever need the .ps file?
Maybe, I do not understand the initial intention, but approximately that
would be my suggestion to
1) Overcome the directory problem in the image environment and
2) the tedious work of always having to invent a new filename.
------------------------------------------------------------------
Just some other thoughts about directories in arguments.
Tom maybe you remember that I modified the \xname command in my
rhxhlx/rhxxname.hlx package to deal with the issue of having something like
\xname{dir/file}
and correctly creating the following section into
htmldir/dir/file.html
In case the rhxpanel is active, it will also take the panel icons from
htmldir/pics/../dir
if there appears \renewcommand{\HlxIcons}{pics} in the .tex file.
Via rhxxname.hlx I modify certain command of hyperlatex.el in order to
make the directory relative to the target place of the html file.
All arguments to pictures (actually to \htmlicon) should be understood
relative to htmldirectory (even if the current node will be generated in
a subdirectory of htmldir).
The code (from rhxxname.hlx)
(defun hyperlatex-relative-prefix ()
(setq hyperlatex-rel-prefix "")
(setq rhx-tmp (hyperlatex-fullname hyperlatex-node-number))
(while (string-match "/" rhx-tmp)
(setq rhx-tmp (replace-match "" t t rhx-tmp))
(setq hyperlatex-rel-prefix (concat hyperlatex-rel-prefix "../" )))
hyperlatex-rel-prefix)
(defun hyperlatex-relative-fullname (node-number)
(concat (hyperlatex-relative-prefix)
(hyperlatex-fullname node-number)))
simply takes the directory part of the current node (which is identical
to the directory part of the corresponding \xname command) and generates
the corresponding directory string that must be prepended to reach
htmldir from the current node.
Example: \xname{dir1/dir2/file}
html-relative-prefix --> ../../
So ../../dir1/dir2 should be equal to htmldirectory.
Note that I do not handle absolute paths, because I think that every
generated stuff should go below htmldirectory.
Best
Ralf
|
|
From: Jay B. <bel...@tr...> - 2004-08-26 18:49:04
|
Ralf HEMMECKE <hem...@ri...> writes:
...
> >>> \begin{image}{directory/name} ... \end{image} Hyperlatex couldn't
> >>> deal with that before and it can't deal with it now.
>
> Well, with hyperlatex-relative-prefix it is easy.
...
> If I am not wrong then everything works fine if htmldir is ".".
You mean still works fine, I hope.
...
> In the \endimage code in hyperlatex.sty appears \the\@imagecount. So why
> not replace the line
>
> \jobname.dvi\space>\space\im...@na...^^J%
>
> by
>
> \jobname.dvi\space>\space\jobname\the\@imagecount.ps^^J%
>
> and the same with
>
> ps2image\space -res\space \image@resolution\space \im...@na...%
>
> replaced by
>
> ps2image\space -res\space \image@resolution\space
> \jobname\the\@imagecount.ps%
The correspoding references in the html file would have to match; how
hard would it be to arrange that? Would that be tricky at all?
Are there any advantages to specifying the image file name?
(Obviously, I don't know the answer to any of these.)
> I would then even add code to ps2image to remove the .ps file.
> Who would ever need the .ps file?
Not me.
> Maybe, I do not understand the initial intention, but approximately that
> would be my suggestion to
> 1) Overcome the directory problem in the image environment and
How does this overcome this problem? Doesn't it just make the
directory in the image environment impossible (rather than
unsupported)?
> Hmmm, I cannot think of a quick solution to strip off the directory part
> with latex, but it should work somehow.
Well, you did come up with a nice solution.
But that wouldn't be necessary if the image name is replaced by a
counter, right?
Jay
|
|
From: Otfried C. <oc...@wi...> - 2004-08-27 07:00:40
|
Jay Belanger writes: > The correspoding references in the html file would have to match; how > hard would it be to arrange that? Would that be tricky at all? > Are there any advantages to specifying the image file name? > (Obviously, I don't know the answer to any of these.) When I originally added image generation to Hyperlatex, I wanted to automatically assign a file name, but I was inable to come up with a reliable way to synchronize the filename between HTML and Latex (think about images that are not shown in one version -- simply counting get's completely out of step them). I think the only way to do this is to have Elisp create a new Latex file for the image generation, and that looked like too much of a mess to me then. Otfried |
|
From: Ralf H. <hem...@ri...> - 2004-08-30 07:42:32
|
Hello,
Otfried Cheong wrote:
> Jay Belanger writes:
> > The correspoding references in the html file would have to match; how
> > hard would it be to arrange that? Would that be tricky at all?
> > Are there any advantages to specifying the image file name?
> > (Obviously, I don't know the answer to any of these.)
>
> When I originally added image generation to Hyperlatex, I wanted to
> automatically assign a file name, but I was inable to come up with a
> reliable way to synchronize the filename between HTML and Latex (think
> about images that are not shown in one version -- simply counting
> get's completely out of step them).
Hmmm, as far as I understand, \begin{gif}{filename}..\end{gif} is for
things that are not easily typeset in HTML, for example, some
mathematical formulae. If \makegifs or \makeimages (in version 2.7) is
defined, images will be generated via latex otherwise the gif or image
environment is
\def\@@@@image{\tex}
\def\endimage{}
So it simply switches to TeX and does nothing. To me that means that the
generated images are solely for the HTML version, so why does counting
not work?
If \makeimages is defined the corresponding images appear (by some
magic) on the first few pages of the dvi file and are extracted by
dvips -p
To syncronise, it would be only necessary to step a counter via elisp
for each \begin{image}.
I know that there still could be a problem when one has something like
\begin{ifhtml}\begin{image}..\end{image}\end{ifhtml}
One could repair this by saying that if \makeimages is defined one
defines in hyperlatex.sty
\newenvironment{ifhtml}{}{}
\newenvironment{iftex}{\comment}{\endcomment}
where the 'comment' stuff is taken from \usepackage{verbatim}. One
should remember that for the html generation, the generated dvi file is
for creating the images and thus an auxiliary file.
Do I see something wrong here?
Ralf
|
|
From: Ralf H. <hem...@ri...> - 2004-08-26 10:41:01
Attachments:
xxx.tex
|
Hello Jay,
> It would be easy enough to have ps2image create the necessary
> directory, but another problem is that file.ps will be created as
> ./dir/file.ps. This would occur (in texfile.makeimage) before
> ps2image is called, and if htmldirectory isn't ".", then the png file
> will be htmldir/dir/file.png. So both directories ./dir and
> htmldir/dir would have to exist. It would be nice if file.ps were just
> ./file.ps, but the ps file name is made by TeX based on the image name
> dir/file, and I don't know how to (reasonably) strip off the directory
> name in TeX.
Well, so let us convince the \endimage macro to generate only the
filename (file.ps) instead of (dir/file.ps).
I have not incorporated it locally into my hyperlatex.sty but as you can
see from the attachment, it should be enough to replace the line
\jobname.dvi\space>\space\im...@na...^^J%
in the \endimage macro by
\jobname.dvi\space>\space\strip{\im...@na...}^^J%
(of course after placing the \strip macro somewhere into the code).
Whether you include the .ps or write it behind } does not matter.
The only restriction of my \strip macro is, that filenames (including
dirs) should not contain a semicolon (;) right after a slash (/). (I
don't think that is a big restriction.)
Ah, and don't forget to convince ps2image to remove this temporary .ps file.
Hope that helps
Ralf
BTW, I still somehow favour an environment where I don't have to give a
filename argument.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X