[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: Richard Heck <rgheck () bobjweil ! com>
Date: 2009-02-06 16:46:21
Message-ID: 498C695D.9030508 () bobjweil ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic