Angus Leeming <[EMAIL PROTECTED]> writes: > > Andreas Vox wrote: > >> It looks like I opened a can of worms with this XFig stuff > >> > > I caught up with my reading (previous DVI file thread on lyx-devel, > > insetexternal, etc.) and I don't envy you > > InsetExternal is actually one of the most powerful concepts in the whole of > LyX. Amazing how such a simple concept can go so far. Asger is a clever, > clever bloke.
Unfortunately "simple in relation to its power" isn't the same as "simple to understand", especially if you missed the initial discussions. I like the concepts of external templates (plugins / import filter) and converters, that's another powerful concept. We need something similar for export, the current solution with latex / docbook / linuxdoc / plaintext methods and additional OutputParams isn't satisfactory. > So, to answer your question, conversions do take place in a single > directory. That's not a restriction of the converters concept per se but > does make the implemetation easier. > > > For my taste this whole external file business is already very > > complicated. A Mover would be a clean solution but also another concept > > to learn. (my head is already spinning from converters, templates, > > previewloaders, graphicloaders, etc.) > > Oh, it isn't that bad really. All the above are clean concepts. Each has > one or more classes to implement that concept. The encapsulation is quite > good. I see still some 'minor' problems: - I haven't figured out yet how to use the math previews for DocBook <graphic> export - No idea how to support InsetExternals Resize/Clip/Rotate transforms for DocBook > > About your code: how do you decide when to copy and when to move? > > Shouldn't there be some parameter in the interfaces? > > Probably. I was just starting the discussion. Here's where I'm coming from: After a good nights sleep I think you shouldn't merge Converters and Movers. But Movers should always 'copy', since you can get a 'move' by doing a copy and a generic 'delete'. Maybe name them 'Relocator' ? ... < However, the problem is that this moving of the original to the temp < directory invalidates any relative file paths inside the original file. < Trying to subsequently fix the *conversion* step is fixing the symptoms of < the problem, not the cause. As is often the case, it is actually really < very messy to do so, because information about the original file location < is no longer available to us. < < However, if these relative paths are fixed at the time the file is moved, < then everything just falls into place. Hm, I just took another look at your can and I think there's another wriggly worm which hasn't crept out yet: Users might have a 'link' or an 'include' semantics in mind with their source files. Your move concept works well with includes, but what about links? Say you have a company logo referenced somewhere, it would get moved to the temp directory and then copied to a new location relative to the master document on export? /Andreas
