Bo Peng wrote:
1/ if it is not done already, support for reading/writing compressed
lyx files should be removed: it has no interested wrt .zip file
version.
I agree. It does not make sense to keep two compressed version. I am
not sure if lyx2lyx decompress compressed lyx file though.
Jose answered this one for me:
def choose_io(self, input, output):
"""Choose input and output streams, dealing transparently with
compressed files."""
Presumably this function could be modified to deal with the new format.
2/ is the new zip base version designed such that a "file" utility can
guess its type based on the first few characters of the binary file?
It could be doable if the first file (the manifest?) is stored instead
of deflated.
Yes. It is a regular zip file. It is not easy to get .lyx or manifest
version without unzipping it first though.
But file will return that it's a gzip file. I've tried it.
4/ I really thing that we should change the extension for bundles (I
like .lyz personally).
a) it allows for automatic processing of files
b) when an end-user receives a .lyz file, he knows that everything
needed is in there. With a .lyx file it is expected that some things
are missing.
If we remove the compression feature, this makes sense. Still, what
about my 'open file.lyx, enable embedding, save to file.lyz' scenario?
This looks weird to me.
I can see wanting embedding to be more transparent, but it's a
trade-off. And maybe it's worth seeing right away that it's an embedded
file, anyway.
By the way, let it not be lost in this discussion how useful this will be.
Richard
--
==================================================================
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==================================================================
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
