On Wed, Apr 02, 2008 at 02:43:58PM -0500, Bo Peng wrote: > OK. Here it is.
I try to come up with "simple solutions". Not sure this will succeed. > 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. So can unpack only to a temporary directory, including a copy of the actual .lyx file. [Actually it does not even have to physically exist, i.e. on Linux /dev/shm or such could be used....] > 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. See above. > 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. So do not let people "unbundle" files but let them "export" from the bundle like a "Save as..." to an "external" directory. > 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. We can have Windows-style "symbolic links" for that, i.e. a small file containing a path to the "external" file (or whatever data is needed to identify the "external" file, so "foo.bib" as "link contents" would be acceptable if we trust TeX to pick it up properly). The "link" itself would be bundled. > This solution requires all files to be > copied to the document directory, which prevents users from having > their own document layouts. No, see above ;-) > 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. This creates the problem of defining a "path" (relative/absolute/links etc...) > 2. When an embedded file is opened, it is opened in the temporary > directory (no readonly problem). Good. > 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. Good, as there is no "unbundling" in my scenario. > 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. I agree with non-automatic unbundling, but the target location should not be fixed. There can be a "export and delete bundle" operation though. > 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. There is no need to actually "bundle again" as there is no unbundling. The bundle is always defined by the contents of the tmp dir. > 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. "Edit" should always edit the bundled (but possibly "linked" version). > 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 "link" content can be "relative" or there can be arbitrary rules to "translate" "link" content, or there could even be _several_ link targets saved in the link, accompanied with logic which one to use. Using qmake syntax (which I do _not_ recommend) this could be something like win32: "C:/whatever/path" else: /usr/local/image/my.img > 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. Using absolute paths tends to break much sooner then using relative paths... > The cleanest solution, as JMarc, Richard, and others have suggested is > to disable embeding of these files. I prefer my "links". > 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. Ich habe fertisch... Andre'
