Dear all,
My thoughts:
I think it is not too uncommon to have two images with the same name in
different directories, such as pics/old/arch.fig and pics/new/arch.fig.
Obviously in such cases the renaming scheme needs to take this into
account, by converting path separators ("/") to another character. However,
that in turn means that that "other character" should not appear in the
file name, so a means of "escaping" it would be needed as well.
For example: Path separators get converted to "_-"; "_" get converted to
"__". In that case, a reverse substitution is always possible.
In short, the solution is workable but has its drawbacks.
If it's possible to fix tex4ht instead, that would be better as tex4ht
users would also benefit. I agree that the code is not so easy to
read/maintain, but this may be a good starting point.
A full "flattening" of path separators has the advantage that we don't have
to worry about the platform the resulting document is used on. In other
words, if we export a nested path name, then the target computer has to
understand the path delimiter in the same way as the source computer. I
guess nowadays any computer understands "/" so maybe this is not an issue
with .odt. If "/" can indeed by used for .odt path names even on Windows,
then keeping the original path names may be the more elegant solution, even
if fixing tex4ht may be a bit difficult.
stefano franchi wrote:
Dear all:
Prannoy just hit upon a problem in text4ht conversion of images to odt format.
This is what text4ht should do:
1. Read the correct reference from the tex file
2. If necessary, covert the image to a suitable (bitmap) format for
inclusion in the odt file
3. copy the converted image to a proper subfolder in the odt file (which
really is a zipped archive, as you know).
The system works fine if the images are in the same directory/folder as the
.tex source file, but tex4ht gets its references screwed up otherwise. It
copies the images to the right "internal" folder (inside the odt file), but
the xml code is incorrect and libreoffice cannot find the images when you
open the file.
Rather than messing up with with tex4ht code, it seems to me the easier
workaround is to copy all the images and the tex source file to a temporary
folder and do the conversion there. This is a similar approach to what LyX
itself does before compiling LaTeX, in fact, and it is also what the native
HTML converter does, I believe.
Issues on which feedback is welcome:
0. General thoughts about the approach (copying images vs. fixing tex4ht
processing)
1. My thinking is that it may be relatively easy to do the copying by
operating on the LyX source code, i.e. via a python script scanning the
Graphics inset. That would tie the tool to the file format, though.
2. For the roundtrip conversion, we also need to keep the original filename
references and store them somewhere in the odt file (in an annotation
field). Are there any platform-related issues on filenames we should be
aware of (encoding, folder delimiters, etc)?
Cheers,
Stefano
--
__________________________________________________
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: +1 (979) 845-2125
Texas A&M University Fax: +1 (979) 845-6421
College Station, Texas, USA
stef...@tamu.edu <mailto:stef...@tamu.edu>
http://stefano.cleinias.org
--
Regards,
Cyrille Artho - http://artho.com/
Give a man a fish, and you feed him for a day.
Teach a man to fish, and he'll invite himself over for dinner.
-- Calvin Keegan
