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
