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

List:       lyx-users
Subject:    Re: Strategies for Writing Co-operation with Non-LyX Users?
From:       David Mertens <dcmertens () gmail ! com>
Date:       2009-02-06 14:51:05
Message-ID: 1206f8220902060651q5ec38276k872f2e9a9419888d () mail ! gmail ! com
[Download RAW message or body]


>
> 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.

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.

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.

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.

David


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