David Mertens wrote:
>> It would be great if ... the .lxy document would be bundled with all images
>> in a .zip file.
>>
>>     
>
> Great idea, but not trivial.  Has this been discussed on the lists before?
> If it has, I couldn't find it.
>
>   
A lot, but mostly on devel. There is, in fact, a script that lives (in 
svn) at development/tools/lyxpak.py that will take a LyX file and create 
a sort of "package" of everything it needs. So, in a way, we have this. 
What's never been agreed is how to have more: how to have a "bundled" or 
"embedded" LyX format that would be more like an OOo file, in that 
everything that was needed would be rolled up in one big piece.

> We would probably want a portable LyX format (.plyx) that would be a
> tarrball or zip of the .lyx file and the various images, possibly including
> their .png previews (used by LyX) and possibly including a finished pdf
> output so the collaborator could view the latest compiled version.  This
> would make document exchange, and therefore collaboration, *much* easier.
> I'm not sure how easily we could encorporate tarring or zipping capabilities
> into the LyX binary itself, but I suspect it's not terribly difficult.
>
>   
There's already a compressed mode, so this is there.

> The problem is that LyX is designed to handle all of the images as external
> documents, so adding 'internal' image capabilities would mean creating lots
> of gui to manage those options.  What if a user wanted to save in internal
> image as an external file on their HD?  That's a new dialog.  Also, you'd
> want to be able to manage internal vs external settings, but how would that
> effect LyX's Graphics dialog box?  You'd have to add a few new elements to
> the Document Settings dialog if you wanted to modify include/exclude
> settings for a compiled .pdf or .ps, or preview .png files.
>
> And of course, .lyx -> .plyx -> .lyx would be nontrivial and the .plyx ->
> .lyx would in the very least require a new set of dialog boxes to handle
> internal images that don't have a counterpart on the user's HD.  Trying to
> minimize the programming load by only allowing import/export would seems
> attractive but comes with its own set of problems, particularly for
> collaboration (which was the point to begin with).  Native support seems
> like the best option.
>
>   
Yes, indeed, these are the problems. And if you do it wrong, you get 
huge security holes. How about bundling a python program into a LyX 
file? There are perfectly legitimate reasons to do that---you're talking 
about the listing. Now let's extract it to $HOME/bin/.

> As you can see, the notion of a new portable file type is a good idea and is
> a valid point of discussion for document collaboration, but it is a thorny
> issue when you get up close to it.
>
>   
Which is why this didn't make it into 1.6.

rh