Georg Baum wrote:
> Angus Leeming wrote:
>
>> Let me try and get my head around the various possibilities. Let's store
>> the .fig file in the lyx document as 'images/img1.fig'. In turn, this
>> .fig file references 'raw.eps', so the path to 'raw.eps' from the
>> document directory is 'images/raw.eps' and the absolute path is
>> '<path to buffer>/images/raw.eps'.
>>
>> 1. Run View->PS etc.
>> The 'images/img1.fig' is copied to the /tmp directory and this
>> copy is
>> modified there to contain '<path to buffer>/images/raw.eps'. XFig will
>> be happy and all will be well. We'll see the raw.eps image in the final
>> PS file.
>
> Yes. Note that raw.eps is already included (not referenced) in
> <mangled file name of images/img1>.eps in the temp dir.
Oh, cool. I sort of new that already, but thanks for reminding me.
>> 2. Export->Latex
>> buffer.tex will include the snippet:
>> \input{images/img.pstex_t}
>> It is the user's responsibility to generate 'images/img.pstex_t'
>> correctly.
>
> No. This is 1.3 behaviour, 1.4 creates 'images/img.pstex_t' and
> 'images/img.eps.' This is alo a case where the converter is called on the
> original file and therefore modifies it :-(((
Not so. It modifies a COPY of the original file. That's a big difference.
Ok, so the bottom line is that a call to
Export->Latex
results in everything that would be needed to compile buffer.tex being
placed in the /tmp/lyx_tmp.../lyx_tmpbuf0/ directory? The only conceptual
problem thereafter is working out which of these files to 'return' in a
'buffer_latex' directory. (This is something we don't do but maybe should
consider doing in the future?)
> Another problem is that fig2pstex.sh does not know of latex's stupid
> interpretation of relative filenames (relative to the master document,
> not the included one. Therefore images/img.pstex_t contains
> \includegraphics{img}, and this fails of course.
Ok, I understand your point. I don't think that it's right because my
'nasty' hack changes that to \includegraphics{<absolute path to>/img}, no?
>> 2. Export->DVI
>> Should the DVI file reference 'images/raw.eps' or '<path to
>> buffer>/images/raw.eps'
>
> None of these two. It references the mangled name of 'images/img.eps',
> because the dvi is created in the temp dir.
Good.
> I hope you are not anymore.
I have the feeling that all this stuff is all more complicated than it
needs to be.
Our concept of a file is actually quite involved.
// If filename is an absolute path then it can be found with
// no other information.
string filename;
// If, however, filename is a relative path, then we should
// look for it relative to the buffer path.
string buffer_path;
// If we don't find it there, then we should look for it
// relative to some environment-variable specified path.
string environment_variable
There's probably other stuff involved too, including the phase of the moon
and the color of the Luke Skywalker's light sabre.
I tried to start wrapping all this up in a class (filename) but got lost in
the intricacies. I still think that doing so would make life a lot easier.
--
Angus
