Bo Peng wrote:
Now with the full path we are placing even more information in the lyx file
than before.
This assertion, 'placing even more information in the lyx file than
before', is plain wrong. Embeding is not placing *more* information in
the lyx file. It places the *same* information in the .lyx file as
before regarding the filepath issue. If you place filename.png in .lyx
file before, filename.png is used now. If you place /path/to/filename
in .lyx file before, /path/to/filename is used now.
I understand that this is a problem, but it is *not* a problem with
embedding. This is my basic understanding of the issue.
Yes, but there are a few points you seem to be missing.
First, many of us think that this discussion has revealed a security
problem with the existing LyX file format. (It seems worth noting that
OOo, for example, does not store this kind of information.) It's not at
all clear what to do about it, but let's not make the problem worse than
it is by making additional uses of the path information we're wrongly
storing. Right now, that information is used only to locate the file we
need. On your proposal, it would also be used for something else,
namely, update from external file, etc. But it does not seem to *need*
to be used for the update business, since we have the session-based
alternative.
Second, even waiving the preceding, what we are discussing are
enhancements to LyX that are specifically designed to support document
sharing. I'll guess that the original LyX format was not really designed
with that in mind. But however that may be, if we're now designing a
format for sharing, then we now need to be more sensitive to security
concerns. If we can do without path information, then we should. And
once the file is embedded, bundled, or whatever, then the original path
information can be discarded, since it is no longer being used to find
the file, and session-based information can be used for update, etc, if
that is really wanted. Moreover, we could encourage users to share only
"bundled" files: File> Export> Bundle.
But there are other ideas, too. Suppose we had bundling in the form it
exists in my private branch. What this does is copy files you reference
into a special subdirectory of the document directory. Then we would
NEVER have to store path information in the LyX file except to that
subdirectory. If you put your files somewhere TeX will find them, then
LyX can just use the filename, and that's all we'll store; we can call
kpsewhich when the file is selected to find out if we can find it that
way. If we can't find it that way, then LyX could offer to copy the file
for you to filename.lyx.dir, just as if you were working in bundled
mode. So this would be a kind of "partial" bundling, but it needs no
special support.
Another idea: We could even call kpsepath to find out where TeX would
find the file, and offer instead to copy it to one of those directories.
If the user declined to copy it, then we'd still just store the
filename, and then the user would need to update TEXINPUTS himself.
Perhaps we could even help with that. We could store path information in
the session or preferences file and then use it to update TEXINPUTS,
BIBINPUTS, or whatever, and maybe even provide a simple UI for managing
this information. And none of that would be very difficult to achieve.
These are just ideas. But enough, I hope, to make it clear that there
are lots of alternatives to what we are doing now.
Richard
