Dear all, Two approaches to embed or bundle external files have been presented in the 'alternative to individual embedding?' thread. If you are interested, but did not have time to follow the heated discussions, here is a summary.
Approach one: individual embedding. 1) Each and every external file can be embedded individually, using an embed checkbox in related inset dialogs. 2) The embedded files are written directly in the '.lyx' file encoded in base64. 3) If users provide a password, the original filenames of embedded files are saved in .lyx file. Otherwise, the information is lost. 4) Global 'embed-all' and inset-level features (undecided yet) such as 'un-embed', 'update from external file' will be provided. These features can make use of file link information if they are available. For example, 'extract all embedded files' will be able to recover the .lyx file and external files in their original directory structure. This achieves full reversibility between 'embed all' and 'extract all embedded files', which are called 'bundle' and 'unbundle' in the second approach. Major benefits: 1) There is no change to existing .lyx files. The .lyx format is still in plain text. 2) Users can work with external, potentially out of tree, files as before. 3) Users can embed/un-embed individual inset, bundle/unbundle all external files, without loss of information. The criticisms: 1) These 'embed' checkboxes cluster the inset dialogs. 2) The .lyx format is more difficult to work with than a zip format (approach two). Base64 strings may confuses index-generators such as google desktop. My answers: 1) Individual embedding has its own advantages. There is no alternative because this approach is characterized by not having a global bundled mode. 2) The plain text file is more svn friendly, easier to work with for tasks other than extracting external files. I do not really care about index-generation applications. I also pointed out that this format is more natural for individual embedding. (No zip/unzip states). Overall, I think this approach is not intrusive, and without any major shortcoming. Approach two: 1) A 'bundled mode' is introduced. File format and working style are preserved in 'unbundled mode'. 2) In the bundled mode, all external files are copied to a subdirectory filename.lyxdir. 3) Switching from unbundled to bundled mode will move all external files to this subdirectory. 4) Switching from bundled mode to unbundled mode will not move any file. It merely stops copying files to this directory. 5) Original filenames are stored in a session file. The original user on the original machine can 'update from external' to update the embedded version from the external version. This update process may be automated in some way. 6) If compression is turned on, filename.lyxdir will be zipped to filename.lyx. Major benefits: 1) No change to .lyx file format (but with permanent changes to the content of a .lyx file when switching to bundled mode) 2) The zip format is easier to work with when lyx is not available. Criticisms: 1) Not friendly to existing files. A .lyx file will be permanently changed if it is turned to the bundled mode. Switching back to unbundled mode will not recover the original .lyx file. (Richard said that he does not offer reversibility in this sense.) 2) Troubles with content management systems such as subversion. Other than having to reorganize existing files for existing documents because of 1), users have to guess which files are added to filename.lyxdir during editing to add them to subversion. This is because lyx determines where to put them, under which name. (This is troublesome to me, but maybe not to others) 3) Difficult to work with external files. In the bundled mode, all external files are bundled so users have to rely on (auto) update from external file to make their changes to external files available to lyx. Once a file is bundled, there is no way to unbundle it because there is no individual bundling. Switching to unbundle mode will not unbndle the file, this is potentially very confusing. 4) Can not maintain meaningful external file structure. External files are copied to filename.lyxdir in a predefined structure with possible aliased names to avoid name conflict. It is argued that users can keep their chapter1/figure1.png chapter2/blah structure for 'update from external' purposes, but this option is only meaningful to the orignal author. Also, once these external files are removed (they are not part of the document), the structure is lost. I can continue but I think these are enough reasons not to adopt the second approach, especially when the first approach does not have any major problem. If anyone (JMarc?) still wants to adopt the second approach, please try to evaluate both pros and cons of these approaches. I mean, being particularly fond of the zip format is not enough to justify all the troubles it causes. Cheers, Bo
