Dear all, The only criticism left to my proposed base64 embedding feature is this 'individual embedding' feature. Basically speaking, each dialog will have an 'embed' checkbox, and users can check this checkbox to embed a file, and know if a file is embedded from the status of it. There can be a global 'embed all' menu item but individual embedding status can be changed separately. The major point here is that there is no global embedded or bundled mode so there is no unbundling to worry about.
The criticism to this feature is that 'it clusters the dialog' and make the embedding feature 'come to your face'. I do agree with this judgment but I do not know any better method within my proposed framework, which is characterized by this 'no unbundling' idea. Personally, I do not think the problem is intolerable. Some others also share this view with me because Jose, Abdel and Enrico agreed with this idea. In addition, individual embedding is more flexible and there are certainly good use cases for it. For example, you can embed certain common files (company logo etc) and make frequently updated files (such as your bib file) external. On the other handle, a global bundled mode forces all files to be either embedded or not, and switching between these two modes implies major changes to the document, and can lead to confusion. Richard claimed that his bundling method does not have the filename in .lyx file issue, is easy, less intrusive and have no trouble in unbundling. Fortunately, while I was not able to compare my previous approach to air last time, he has partially implemented his method in his personal branch so that I can have a look at his code this time. Since he is too busy to summarize what he is doing, allow me to try my best and please forgive my potentially wrong interpretation. Richard's approach is characterized by a 'copy to a subdirectory filename.lyxdir' action. When lyx is working in 'bundled' mode, all inserted files are copied to a pre-specified directory under a directory filename.lyxdir. For example, if you insert ../figures/file.png, it will appear as mylyfile.lyxdir/graphics/file.png. When you switch off this 'bundled' mode, things turns to normal. It does not appear to me that this method is intended to make any file format change, but Richard stated in his svn log that he may zip mylyxfile.lyx with mylyxfile.lyxdir so that his bundled format is a zip format. From what I have read, his approach should work like this: 1. Users work as usual in unbundled mode. 2. When the document is turned to 'bundled' mode, a directory filename.lyxdir is created in the document directory. All external files are copied to this directory. Note that even files in the document directory are copied. 3. In the 'bundled' mode, insert ../figures/file.png will be inserted as filename.lyxdir/figures/file.png, subject to filename changes to avoid filename conflict. 4. When users save in 'bundled' mode, filename.lyx is zipped with filename.lyxdir, to possibly to another file named filename.lyz. (I am not sure). 5. If a user turns off 'bundled' mode, things go back to normal (files are not copied back). Saving a file in unbundled mode will save in plain text format. 6. When filename.lyz is opened, filename.lyxdir is created and users would work in the 'bundled' mode. He sketched this method a while ago. I objected it without a second thought and I will certainly object it this time. However, I guess I need to explain why I dislike this idea because it was liked by some developers. 1, This method is more intrusive than my approach, both in user-interaction and in file format. In my approach, users select 'embed', and the file is embedded. There is no change in user-interaction. The file format change is minimal because only the embed lines and the extra begin/end_embedded_files section need to be handled in lyx2lyx. The file itself is still in plain text format. In Richard's approach, the same insert action would lead to different results, depending on which 'mode' the document is in. The file format is now either a directory with pre-specified structure, or a zip file. 2. I dislike the idea of a pre-specified directory structure. Why should filename.lyxdir/graphics, filename.lyxdir/bib is clearer than my chapter1/figure1_1.png..., chapter2/figure2_1, ../all_my_bibs/mybib.bib structure? 3. This method disallows the use of out of tree files, thus disallow the sharing of external files between different .lyx files. 4. The switching between bundle and unbundled mode is non-reversible. For example, when ../figures/figure.png is copied to filename.lyxdir/figures/figure.png during bundling, it is not copied back during unbundling. That is to say, if you work in unbundled mode locally, send your document in bundled mode to your co-author, you can not get your external files back when the document is sent back. In another word, you have to use bundled mode if you intent to share your file with others. 5. This method disallows the use of external file in bundled mode. All files are embedded. For example, when I insert ../figures/figure.png, updating this file will not change the document output. Then, a user might want to 'unbundle' the document to make his updated figure work. No, it will not because the inserted file is still filename.lyxdir/graphics/figure.png, not ../figures/figure.png. There are other (minor) problems but these are enough reasons for me to object this method. During our discussion, Richard insisted that all these are features users can easily get use to. His approach should be used because it is easy, safe and less intrusive to lyx source. Now that my no-unbundling approach does not have any security problem, is also non-intrusive (if not less so), I do not know why users should tolerate all these. Cheers, Bo
