Jean-Marc Lasgouttes wrote:

> To be more precise, there are currently some bugs with for example dvi
> or html export which can only be worked around by not using a tempdir.
> So before forcing everyone to use a tempdir, I would like to
> understand how are these things going to be handled. In particular, I
> am not sure I understand what is the new philosophy for the include
> inset.

When I asked some time ago the only bug that somebody (you?) mentioned was
dvi export. 
Bugzilla has bugs 643 and 1405 about html export.
I thought that the "run in original dir" flag was used for html converters?
I guess that if this flag is honoured correctly html export should also
work with a temp dir, putting the generated files deliberately not in the
tmp dir.

> Georg, could you outline what will be before/after situation for the
> various insets when using a temp dir?

The current situation is a problem because in the case of not using a
tempdir
a) some files that are definitely temporary are created in the working
directory (btw usually without checking if existing files are overwritten)
and
b) we have to handle too many combinations of "nice file" and "using a temp
dir" at different places.

The clean solution would be to have only "using a temp dir and no nice file"
vs. "using no temp dir and nice file".
I used your patch on http://bugzilla.lyx.org/show_bug.cgi?id=605 and adapted
it. The basic idea is that include, external and graphic insets put their
files into the master buffer's temp dir. This is possible if all filenames
are mangled. Then these insets write relative pathnames to the .tex file.
This makes it possible to copy the .dvi file + graphics afterwards. In
addition, the external and graphics insets write their files into a list
that in the case of dvi export is then used to copy all files from the
master buffer's temp dir to the final destination.

I have a working version of all this. The only known bug so far is that the
dvi export fails if two included files include the same graphic, but I
believe I know the source and that I can fix it.

> Something we could maybe do for now is merge all the stuff in the
> patch that is straightforward...

I thought that sending everything at once makes it difficult to understand
the whole thing. Applying first the tempdir part and after that the inset
changes is easy, but the other way round would be more difficult, because
the latter depends on the first.


Georg

Reply via email to