Abdelrazak Younes wrote:
Andre Poenitz wrote:
Base64 blobs have the distict advantage of retaining the possibility to
edit the .lyx file in a text editor - which I used to do quite often...
But Base64 blobs have the disctinct inconvenient that LyX will have to
read all embedded files itself. This will kill the file loading time
if we abuse such method. OK, we could organize the .lyx file so that
all blobs are at the end instead of when they are used (this would
mean that the file loading would have to be done in two parts) but LyX
would have to read these files nonetheless and it does not right now
for most of them; and when it does, it does it asynchronously
(graphics), you can't beat that, can you?
So I think base64 embedding is fine for small files like icons or
logos but zip should be the preferred method for anything bigger.
I had thought of Andre's concern, because I have used perl scripts on my
LyX files, too. But you can just wrap your script in unzip...zip, or tar
-x...tar -c, or whatever we decided to use. We could even provide such a
wrapper in scripts/. And using zip or something would allow you, in
principle, to unzip the file, edit one of the embedded graphics, or even
replace it---say, via something in the script itself---and then zip it
back up. Of course, we could also provide a python script to unpack a
base64-encoded file and then repack it. But then we're providing a
special tool as opposed to harnessing some general-purpose thing people
already have.
The possibility of working with an "unwrapped" bundle---this being, as
JMarc put it, just a "power-user option"---negates all such worries.
Then you would just have a normal LyX file and a directory. And you can
make that distinction, of course, whether you go for global or
inset-specific embedding.
rh
