> > an executive summary (without rhetorics) would be helpful for bystanders > to also chime in...
OK. Here it is. The goal of the embedding feature is to ease the difficulties in sharing .lyx documents, especially those with customized .layout and .cls files such as theses. The current situation is that one has to send all files (.png, .eps, .bib, .bst, .cls, .sty, .layout ...) , possibly in a zip format, the recipient has to unzip it and open the .lyx file. In the 1.4.x days, he had to put .layout to $HOME/.lyx/layouts, install .cls to his tex system, and reconfigure lyx. Thanks to my local-layout patches, this has been the past. Of course, bundling necessary files in a single .lyx file has its own advantages. For example, one can create a thesis template with customized .cls and .layout so that users only need to insert their own contents. The problem seems easy, we simply help users pack and unpack files, but the devil is in the details. More specifically, which files should we embed, are we going to unpack the files automatically, and where should we unpack the files? The simple solution, which is essentially Richard's proposal, is that: 1. we only pack files in or under the document directory. 2. we automatically unpack these files to where they are (document directory) when a .lyx file is opened. I say this is simple because packing and unpacking only happen when a .lyx file is opened or saved. After the file is opened, all embedded objects are external so NO modification to the current inset code is needed. There are, however, a few problems with this approach. Say you have file.packed, with files "file.lyx" and "file.png" inside. 1. Opening file.packed in a readonly directory will fail because you can not unpack to that directory. This is easily the case to our system documents. 2. You do not really want to unpack to where file.packed stays. One example I gave to Richard was that people will be irritated when they double-click a file, and find that his desktop is messed up with all the figures. His solution was then to unpack to a subdirectory "somedir". Because .cls, .layout etc have to be located in the same directory as .lyx, I guess one can put .lyx in this directory as well, or as he suggested and I assumed doable, to set some sort of $TEXINPUT so that these files can be used. However, remember that you pack "file.lyx" and "file.png" in dir to file.packed, and when you open file.packed, you end up with "mydir/somedir/file.lyx" and "mydir/somedir/file.png". I mean, you do not get your files back even on the same system. 3. There is a clean up problem with this approach. There will be files or a directory left after the .lyx file is closed. The problem here is that if you keep your .lyx file in embedded mode, you can remove somedir when file.packed is closed. However, the files have to be kept if people would like to keep unbundled. I do not know how this can eventually work out (maybe remove file.packed instead?). Richard's solution was that we do not clean up, which is unacceptable to me. 4. What about files not in or under document directory? It is pretty common to link to ../figures/fig.png, or refer to /my/research/bib/allmybib.bib. This solution requires all files to be copied to the document directory, which prevents users from having their own document layouts. Enough said, the current implementation solves these problems this way: 1. All files can be embedded, embedded files are saved in the same or aliased names under the document temp directory. However, the *original* paths are saved, and appear in the inset dialogs. This is the major difference between this design and the word/ooffice way of embedding. 2. When an embedded file is opened, it is opened in the temporary directory (no readonly problem). The document know where these files are (embedded or external), and generate .tex code correctly when the document is compiled. That is to say, the .lyx file can be compiled without unbundling. 3. A user can 'unbundle' the .lyx file, which copies all embedded files to their external locations. (Remember that we save these paths). There is no automatic unbundling. 4. A user can 'bundle' the .lyx file again, which copies embeddable external files to the .lyx temp directory. The design tries to make bundle and unbundle completely reversible, without loss of information. 5. A user can "extract" and "update from external file" a single embedded file. If 'edit' is provided for an inset, the external or embedded version is edited. 6. A user can edit .lyx file in bundled mode. In this mode, all embedded files are immediately copied to the lyx temp directory. Modifying the external file has not effect on latex output. Again, lyx knows which files to use to produce output. Some people dislike this feature, but this the only way out when unbundling is not automatically done. This design is more complicated than Richard's but most of the coding has been done. Using my own word, "it should work fine after fixing twenty or so bugs". However, people are unhappy about one particular problem: Files with full path name can be embedded, and works as usual when embedded. However, it can be troublesome when this file is extracted under a different operating system. E.g. how would you extract /usr/local/image/my.img under windows? The current solution is that users can choose to save to a different directory (with needed changes in .lyx file), but the problem may happen again, assuming another absolute-path file is used, if the .lyx file is sent back to the original file system, and extract over there. The cleanest solution, as JMarc, Richard, and others have suggested is to disable embeding of these files. I dislike this solution because the embedding feature will then be crippled. My arguments were that 1. As long as one side of the players does not unbundle the file, or save the file to a relative path, the problem is resolved. Because the current implementation allows the word/ooffice style of embedding, which can be natural to many users, I do not consider unbundling as a necessary step to work on a document. (Richard and JMarc disagree with me on this.) 2. Embedding such files are important, as I have said above. 3. This is not really our problem because users want to have access to the same file, which can not be represented as the same on different systems. The problem would be more serious if a user would like to do this manually, .i.e., copy files to another system and make a .lyx file compile. Also, the current lyx 1.5.x does not help at all in this situation. My point is that embedding has improved the situation a lot, why criticizing it as not being perfect? 4. A proper solution to this problem is not difficult at all. We can warn users when s/he would like to save such a file in bundled mode. Because the problem is easy to understand (no /usr/local under windows etc), the user can choose to embed it as it is if s/he will not unbundle it under a different system, or his/her co-author will do only minor editing in bundled mode. Otherwise, s/he can copy the file to the document directory with help from lyx. This is not quite a short summary, but hopefully explains the current design well, and can help people make the choice. To answer Jose's question why I chose a design *between* latex and word/ooffice style, I have to say that the current design takes advantages of both worlds, and is very natural to me. I certainly welcome criticisms to my design and new ideas. Cheers, Bo
