"Bo Peng" <[EMAIL PROTECTED]> writes: >> 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.
What about using the comment field of the zip file? It appears in the first bits of the binary IIRC. The comment could actually be the manifest and start with an indication of the lyx format (and maybe version). >> 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). > > This is a good idea but I am not sure if python/zipfile can read the > first few bytes of the first file easily. Let's forget about this one for now. >> 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. Is it so weird? When you export to LaTeX, you get a .tex file. >> 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. > > It is there. Could you elaborate? JMarc
