On Wed, Sep 22, 2010 at 11:30 AM, Richard Heck wrote:
> On 09/22/2010 12:56 PM, Erich Hoover wrote:
>
>> I've been starting to get a few of the people I work with to convert to
>> LyX and I've been noticing that when sending documents between authors it
>> would be convenient to not always be ZIP
On 09/22/2010 07:30 PM, Richard Heck wrote:
For now, you might want to look at the lyxpak.py script, written by
Enrico Forestieri, which is a lower-tech approach to the same problem.
The script lives at development/tools/lyxpak.py in the source and can
be downloaded from:
http://www.lyx.or
On 09/22/2010 12:56 PM, Erich Hoover wrote:
I've been starting to get a few of the people I work with to convert
to LyX and I've been noticing that when sending documents between
authors it would be convenient to not always be ZIPping up all the
dependencies. Is there any chance that patches t
I've been starting to get a few of the people I work with to convert to LyX
and I've been noticing that when sending documents between authors it would
be convenient to not always be ZIPping up all the dependencies. Is there
any chance that patches to allow embedding files in LyX documents would g
"Bo Peng" <[EMAIL PROTECTED]> writes:
> When I re-think this problem, the current approach should work just
> fine. It is true that these files might be anywhere, but EmbeddedFile
> will *not* embed them if it can not find it. As long as the latex
> output is corrected written through the use of a
> I do not think that even a InsetGraphics object has to be a valid
> file. If I have Logo_INRIA.pdf in my TeX path at work, I want to be
> able to use it. Currently, LyX does not find graphics through
> kpsewhich, but there has been a request for that (and I think we
> should do it). Therefor
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> I'm skeptical that this will solve the problems. The issue doesn't
>> really have anything to do with relative versus absolute paths. If I
>> choose "biblio" as my BibTeX file, that is NOT a pathname.
>
> I see your point now. Unlike InsetInclude and Ins
Bo Peng wrote:
I think the approach in my patch can be made to work. I can embed the
file just fine, and it gets extracted just fine. But I have seen some
issues with latex output. Sometimes it works, sometimes it doesn't. But
I'm thinking this can be made to work. At the very least, we can g
buffer);
Index: src/EmbeddedFiles.cpp
===
--- src/EmbeddedFiles.cpp (revision 24005)
+++ src/EmbeddedFiles.cpp (working copy)
@@ -54,6 +54,16 @@
}
+EmbeddedFile::EmbeddedFile(std::string const & file,
+ std::string const & inz
> I think the approach in my patch can be made to work. I can embed the
> file just fine, and it gets extracted just fine. But I have seen some
> issues with latex output. Sometimes it works, sometimes it doesn't. But
> I'm thinking this can be made to work. At the very least, we can give a
>
rc/EmbeddedFiles.cpp
===
--- src/EmbeddedFiles.cpp (revision 24005)
+++ src/EmbeddedFiles.cpp (working copy)
@@ -54,6 +54,16 @@
}
+EmbeddedFile::EmbeddedFile(std::string const & file,
+ std::string const & inzipName, bool
> I'm skeptical that this will solve the problems. The issue doesn't
> really have anything to do with relative versus absolute paths. If I
> choose "biblio" as my BibTeX file, that is NOT a pathname.
I see your point now. Unlike InsetInclude and InsetGraphics where a
file must be a file, this
src/EmbeddedFiles.cpp (working copy)
@@ -54,6 +54,16 @@
}
+EmbeddedFile::EmbeddedFile(std::string const & file,
+ std::string const & inzipName, bool embed, Buffer const & buf)
+ : DocFileName("", false), inzip_name_(inzipName), inset_list_()
+{
+ DocFileName::set(file, buf.
Andre Poenitz wrote:
On Thu, Mar 27, 2008 at 09:33:20AM -0500, Bo Peng wrote:
In the case of InsetBibtex, I think maybe an approach more like the one
in InsetInclude might work, where there aren't any "local" EmbeddedFile
objects but only the ones in the Buffer-level EmbeddedFileList.
Ins
> I'm fairly convinced that we should not be using the
> EmbeddedFiles stuff to represent the parameters here. That just seems
> like mixing up the wrong things.
Why not? We need to store filenames (I know I need to keep the
original filenames), and the embedding status. Using a EmbeddedFiles
> I'm fairly convinced that we should not be using the
> EmbeddedFiles stuff to represent the parameters here. That just seems
> like mixing up the wrong things.
Why not? We need to store filenames (I know I need to keep the
original filenames), and the embedding status. Using a EmbeddedFiles
ob
Andre Poenitz wrote:
On Thu, Mar 27, 2008 at 04:30:08AM -0400, rgheck wrote:
Attached is a more radical sort of patch, one that disentangles InsetBibtex
from the EmbeddedFiles stuff a bit, while making the logic a lot simpler, I
think. It's at least proof of concept that this kind if disenta
ssue with
> InsetInclude::setParams(): Presumably the Buffer needs to know about it
> if the embedding status has changed.
EmbeddedFiles was the center of the embedding feature, but not now.
Every inset takes care of its own embedded files, and conflict etc are
only handled when necessary. Th
On Thu, Mar 27, 2008 at 09:33:20AM -0500, Bo Peng wrote:
> > In the case of InsetBibtex, I think maybe an approach more like the one
> > in InsetInclude might work, where there aren't any "local" EmbeddedFile
> > objects but only the ones in the Buffer-level EmbeddedFileList.
> > InsetBibtex co
Bo Peng wrote:
>
At least my most recent bit encapsulates that.
I have not looked at the svn, have your committed your patch? Will you
be able to wait for me to make EmbeddedFile relative-path friendly?
No, I haven't committed it yet. And see the other note on this.
rh
Bo Peng wrote:
Comments welcome.
This is pretty radical. You basically have a relative-path version of
EmbeddedFile in InsetBibtex and convert to EmbeddedFile if needed.
In a way, but there's no EmbeddedFile object stored there at all. Just
the old parameter info. We build EmbeddedFi
On Thu, Mar 27, 2008 at 04:30:08AM -0400, rgheck wrote:
>
> Attached is a more radical sort of patch, one that disentangles InsetBibtex
> from the EmbeddedFiles stuff a bit, while making the logic a lot simpler, I
> think. It's at least proof of concept that this kind if disentanglement can
> be
> >
> At least my most recent bit encapsulates that.
I have not looked at the svn, have your committed your patch? Will you
be able to wait for me to make EmbeddedFile relative-path friendly?
Cheers,
Bo
Bo Peng wrote:
In the case of InsetBibtex, I think maybe an approach more like the one
in InsetInclude might work, where there aren't any "local" EmbeddedFile
objects but only the ones in the Buffer-level EmbeddedFileList.
InsetBibtex could have a vector of EmbeddedFile* instead, where these
> Well, we need some general solution, because there are similar problems
> elsewhere. If you have a file that contains a path to an included file,
> for example, it can be changed simply by opening and saving the file. In
> particular, it will always be converted from an absolute to a relative
> Comments welcome.
This is pretty radical. You basically have a relative-path version of
EmbeddedFile in InsetBibtex and convert to EmbeddedFile if needed.
How about making EmbeddedFile a standard-alone class that does not
derive from DocFileName? We simply save whatever path, relative or
absol
Attached is a more radical sort of patch, one that disentangles
InsetBibtex from the EmbeddedFiles stuff a bit, while making the logic a
lot simpler, I think. It's at least proof of concept that this kind if
disentanglement can be done. Note that it also disentangles EmbeddedFile
from the bib
On Wed, Mar 26, 2008 at 07:54:03PM -0400, rgheck wrote:
>> Andre sayeth:
>>
>> On Wed, Mar 26, 2008 at 05:29:22PM -0400, rgheck wrote:
>> > [...]
>> > Comments welcome. And see the long FIXME about remaining issues.
>>
>> > +
>> > + docstring embed(getParam("embed"));
>>
>> We use
>>
>>
Bo Peng wrote:
I tried using updateParam() after introducing getTeXFile, but that
didn't work. The problem is that there's no way to tell when you get
back from EmbeddedFiles what the ORIGINAL path was. Things like: biblio,
../biblio, /home/me/biblio, etc, all look the same to EmbeddedFiles a
> I tried using updateParam() after introducing getTeXFile, but that
> didn't work. The problem is that there's no way to tell when you get
> back from EmbeddedFiles what the ORIGINAL path was. Things like: biblio,
> ../biblio, /home/me/biblio, etc, all look the same to EmbeddedFiles at
> that
Andre sayeth:
On Wed, Mar 26, 2008 at 05:29:22PM -0400, rgheck wrote:
> [...]
> Comments welcome. And see the long FIXME about remaining issues.
> +
> + docstring embed(getParam("embed"));
We use
docstring embed = getParam("embed");
[Several occurences]
If you say so, OK. But the
Bo Peng wrote:
Comments welcome. And see the long FIXME about remaining issues.
Why do you remove updateParam and manipulate (in add/remove database
etc) these parameter strings again and again? The original idea was to
change EmbeddedFiles, and write these strings from the file list each
> Comments welcome. And see the long FIXME about remaining issues.
Why do you remove updateParam and manipulate (in add/remove database
etc) these parameter strings again and again? The original idea was to
change EmbeddedFiles, and write these strings from the file list each
time.
Bo
On Wed, Mar 26, 2008 at 05:29:22PM -0400, rgheck wrote:
> [...]
> Comments welcome. And see the long FIXME about remaining issues.
> +
> + docstring embed(getParam("embed"));
We use
docstring embed = getParam("embed");
[Several occurences]
Andre'
The attached patch solves the problem about relative pathnames and
BibTeX files...at least, it solves most of the problem. You can at least
use relative pathnames now, though they won't always work correctly with
the embedding feature (though no worse than before).
I've also fixed up some of
Bo Peng wrote:
Can you explain to me what the embed parameter here is supposed to mean?
I have e.g.
\begin_inset CommandInset bibtex
LatexCommand bibtex
bibfiles "/home/rgheck/files/bibtex/biblio"
embed "./LyX.Embed.Dir.Abs//home/rgheck/files/bibtex/biblio.bib"
options "plain"
The b
> Can you explain to me what the embed parameter here is supposed to mean?
> I have e.g.
> \begin_inset CommandInset bibtex
> LatexCommand bibtex
> bibfiles "/home/rgheck/files/bibtex/biblio"
> embed "./LyX.Embed.Dir.Abs//home/rgheck/files/bibtex/biblio.bib"
> options "plain"
The bib file i
Bo Peng wrote:
I have to say that it seems messy to me that we're effectively storing
two sets of things that have the same significance: params["bibfiles"],
on the one hand, and the embedded file list, on the other. This makes
the logic in InsetBibtex, on which I worked a fair bit and would
> I have to say that it seems messy to me that we're effectively storing
> two sets of things that have the same significance: params["bibfiles"],
> on the one hand, and the embedded file list, on the other. This makes
> the logic in InsetBibtex, on which I worked a fair bit and would have
> t
Stefan Schimanski wrote:
I've traced the problem with citations for a while, and I'm still
kind of puzzled. This has something to do with the fact that
EmbeddedFile objects, since they inherit from FileName, always store
absolute pathnames. But in many of these cases, it seems that the
Embedde
I've traced the problem with citations for a while, and I'm still
kind of puzzled. This has something to do with the fact that
EmbeddedFile objects, since they inherit from FileName, always store
absolute pathnames. But in many of these cases, it seems that the
EmbeddedFile objects actually
Bo Peng wrote:
Is there any progress on this? Is it a problem by design of the new
file handling? Or just a bug? What does "There are a lot of work in
this area." mean? Is anybody actively working on this?
These files are now EmbeddedFiles and their latex output names are
currently wron
> Using a map for this purpose would fit exactly. If you
> need also the reverse translation then it might not be the best fit
> anymore
There are reverse translations. The problem is that *both* names have
to be checked because EmbeddedFiles does not know in advance which
name will be checked.
>
Bo Peng wrote:
> Now, JMarc mentioned that he would like to use a map for embedded
> files.
That seems natural to me: At some place you have to translate from external
to embedded names. Using a map for this purpose would fit exactly. If you
need also the reverse translation then it might
> I am solving this problem by
A patch has already been submitted. Please test it using lyx' User's guide.
Bo
> This is actually also related to the original problem with [Embedding
> discussion 1], do we want multiple entries for multiple insets
> referring to the same file?
I am solving this problem by
1, store a list of ParConstIterator for multiple insets in a EmbeddedFile item.
2. display the file i
Dear all,
Thanks to Edwin, the embedding dialog is working again. It now has a
list of embedded files, with embedding status (true/false) indicated
by checkboxes. There are five buttons: select (embed selected files),
unselect (dis-embed selected files), add (add a file), extract
(extract
enabled (disabled by default), .lyx file can embed
> graphics,
> +listings, bib file etc.
> +
> +2. Embedding of certain files are automatic (graphics, bib etc), and
> +other files can be embedded manually.
> +
> +3. Embedded file.lyx file is a zip file, with file.ly
+
+
+void EmbeddedFiles::update()
+{
+ // invalidate all files, obsolete files will then not be validated by the
+ // following document scan. These files will still be kept though, because
+ // they may be added later and their embedding status will be meaningful
+ // again (thinking of cut/paste
Dear all,
Attached please find the second patch for the embedding feature. The
key points are:
1. void registerEmbeddedFiles(Buffer const &, EmbeddedFiles &,
ParConstIterator const &) const;
An inset registers embedded files with an EmbeddedFiles class.
2. void EmbeddedFiles::up
50 matches
Mail list logo
