Andreas Vox wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > > < What to do if the XFig picture *includes* an EPS figure? Our new, > < improved handling of the conversion of such XFig files to > EPS,PSTEX_T < in the tmp directory doesn't work as it did in LyX > 1.3.x, because the < included EPS figure is not moved. > ... > < If we have the buffer directory and if we can ascertain the XFig > code < for 'picture', then it is trivial to use sed to convert this. > < > > XFig processor yes, XSLT processor no ? ;-) > > < Is such a strategy possible? Thoughts? > > Looks like this is getting a mess. This looks as if LyX has to > outsmart all possible converters ...
No it doesn't. It means that an *external* wrapper script has the information necessary to do the job. Individual converters can be as dumn or as smart as they like. > Alternative A) > Leave the xfig file where it is and force all converters to > understand a '-d' flag for the output directory. Nope. Bad idea for all sorts of reasons. The main one being that you are using the directory in which your important files are as a temp directory in which you process these files. We have an extremely powerful and successful mechanism to avoid this and it WORKS. > Alternative B) > Force the user to register all external files with LyX. This is indeed a possibility. However, I think it adds (real) complexity for the benefit of only a few corner cases. Yes, I consider my own problem to be a corner case. I think that such corner cases are probably best handled by the controlling script in this case. > I would prefer A) if it is feasible. You're going to be dissappointed then ;-) -- Angus
