José Matos <[EMAIL PROTECTED]> writes: > First: the compressed feature is done in such a way that inside lyx the user > should not care if the file is compressed or not. The same should happen for > embedded files. > > Second: people who write scripts to modify should know better. :-) > We should, if necessary, start a repository of simple scripts to manipulate > lyx files that takes into account the new complexities.
I disagree 100%. One thing that people like about LyX files is that they are text files on which one can do straightforward search and repalce without looking for fancy python libraries nobody cares about. I think we should keep some kind of simplicity. 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. 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. 3/ another option would be to make sure that the .lyx file is first, so that utilities like zcat can read them transparently like gzipped files (not sure about the utility of that though). 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. 5/ if we want our bundle format to be useful, it should have a directory form (if possible compatible with OSX bundles). The big advantage is that such files could be possibly put under version control. We do not have to do that right now, but the design should reflect this need. BTW, is there a place where the format of a LyX bundle is defined? A wiki page would be nice. These things are important, since we are going to live with this file format, and we should do it right since the first time. JMarc
