[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lyx-devel
Subject:    Re: Alternative to individual embedding?
From:       Richard Heck <rgheck () bobjweil ! com>
Date:       2008-05-13 20:53:31
Message-ID: 4829FFCB.8010005 () bobjweil ! com
[Download RAW message or body]

Bo Peng wrote:
>> Well, maybe you're mirroring the original directory structure, in a way
>> like chroot. But you're not "recreating" it. And I don't see the advantage
>> of doing that myself.
>>     
>
> This is Enrico's idea. The lyx file may be put several levels under
> the new directory so that the original '../../figures/blah' path can
> be restored.
>
> The advantage of this approach is that it allows the use of out of
> tree files, and recovery of the original links when a file is
> unbundled. Taking (again) the example of user's guide, if a user sends
> us an updated version, we can extract all embedded files and update
> our user's guide with it. Such a feature is important when you work
> mostly with external files, but need to send your document back and
> forth to your co-authors.
>
>   
Well, if that's the idea, then I'm with Edwin (was it?) who proposed 
just using a python script for this kind of purpose. We even have one, 
more or less. We don't need a special feature in LyX just to bundle up 
the files in this kind of case. The same goes for the other case you've 
mentioned: working with a co-author where you both want to use 
"external" files. There is no need to support this in LyX itself.

It seems to me, and apparently also to at least some others, to be 
contrary to the *nix spirit of specific tools for specific jobs--- the 
point being not that it's the *nix spirit, but that it's the right way 
to do things. Adding this kind of feature to LyX complicates our code 
for very little gain.

Richard

[prev in list] [next in list] [prev in thread] [next in thread]