> I thought you wanted to allow things to unbundle to arbitrary locations? Or
> are you now just allowing them to update from such locations? I can't follow
> everything that's happened.
If you want the latest progress on this issue:
Still the same:
1. I allow arbitrary files to be embedded,
2.
Bo Peng wrote:
You mean like when microsoft thought it would be nice to let people
send exe files by e-mail and execute them by double clicking? The kind
of feature that should not be a problem for anyone...
The key point is that 'you do not have to', because the current
implementation
Bo Peng wrote:
Actually, after all these messages, I have not heard a good summary of
what *you (or Richard)* have in mind, a workable solution that avoids
the problems I mentioned in the first message, a good solution to
allow me to share different files from the same .lyx document.
I've out
On Fri, Apr 4, 2008 at 2:50 PM, José Matos <[EMAIL PROTECTED]> wrote:
> On Friday 04 April 2008 20:37:20 Bo Peng wrote:
> > I can compile the .lyx file on machine A but not on machine B which
> > has that file, but not the session file.
>
> You know that this is not the usual case.
> If you ins
On Friday 04 April 2008 20:37:20 Bo Peng wrote:
> I can compile the .lyx file on machine A but not on machine B which
> has that file, but not the session file.
You know that this is not the usual case.
If you insist a python script to seed the session file is easy. :-)
> Actually, I would suppor
> I am proposing that this information should be made local to the machine
> where
> the file was created.
>
> Just to illustrate my point I propose that instead of this:
>
> What is the problem with this approach?
I can compile the .lyx file on machine A but not on machine B which
has that f
On Friday 04 April 2008 19:49:45 Bo Peng wrote:
> I transmit the file content, as well as filename. The filenames serve
> some purposes so they are functional. I mean, if there were a problem,
> I am not making it worse.
>
> Bo
I am proposing that this information should be made local to the machi
On Fri, Apr 4, 2008 at 1:37 PM, José Matos <[EMAIL PROTECTED]> wrote:
> On Friday 04 April 2008 15:18:58 Bo Peng wrote:
> > Open *any* version of lyx, insert anything like graphics, child
> > document, external, browse to /var/log/blah, save you lyx file. You
> > will see /var/log/blah in your .
On Friday 04 April 2008 15:18:58 Bo Peng wrote:
> Open *any* version of lyx, insert anything like graphics, child
> document, external, browse to /var/log/blah, save you lyx file. You
> will see /var/log/blah in your .lyx file.
If you transmit solely the file it is non-functional, so we are not
On Fri, Apr 04, 2008 at 05:16:51PM +0800, John McCabe-Dansted wrote:
> On 4/4/08, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> > "Bo Peng" <[EMAIL PROTECTED]> writes:
> > > If the majority of the users keep their files in a subdirectory, my
> > > feature is not in the way of anything, right?
> > This is my proposal, which can embed any file. The files will be in
> > the bundle, and if they are extracted, they can only be extracted to
> > the document directory.
>
> I am OK with that, if 'document directory' means 'a special directory
> that only belongs to this document'.
Great.
"Bo Peng" <[EMAIL PROTECTED]> writes:
> This is my proposal, which can embed any file. The files will be in
> the bundle, and if they are extracted, they can only be extracted to
> the document directory.
I am OK with that, if 'document directory' means 'a special directory
that only belongs to
On Fri, Apr 4, 2008 at 10:40 AM, Jean-Marc Lasgouttes
<[EMAIL PROTECTED]> wrote:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
>
> > Also about your uneasiness of embedding arbitrary files through
> > document->settings. Whatever embedding solution you choice, users can
> > embed arbitrary files throu
> > But if lyx forbids, or make it very difficult, to make a file that can
> > be compiled anywhere, it is lyx' problem.
>
> You can put the files you want inside the bundle.
This is my proposal, which can embed any file. The files will be in
the bundle, and if they are extracted, they can only
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Also about your uneasiness of embedding arbitrary files through
> document->settings. Whatever embedding solution you choice, users can
> embed arbitrary files through InsetGraphics, InsetInclude etc.
The files will be embedded only if the embedding code d
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> Having a LyX file that does not typeset is a not a problem of the same
>> magnitude as having a LyX file that creates files at arbitrary places
>> on your hard disk.
>
> But if lyx forbids, or make it very difficult, to make a file that can
> be compiled
On Fri, Apr 4, 2008 at 9:28 AM, Bo Peng <[EMAIL PROTECTED]> wrote:
> > > Open *any* version of lyx, insert anything like graphics, child
> > > document, external, browse to /var/log/blah, save you lyx file. You
> > > will see /var/log/blah in your .lyx file.
> >
> > And? What kind of evil c
> > Open *any* version of lyx, insert anything like graphics, child
> > document, external, browse to /var/log/blah, save you lyx file. You
> > will see /var/log/blah in your .lyx file.
>
> And? What kind of evil can we do from there?
Ask Jose. He insisted that I should not save absolute path
> You mean like when microsoft thought it would be nice to let people
> send exe files by e-mail and execute them by double clicking? The kind
> of feature that should not be a problem for anyone...
The key point is that 'you do not have to', because the current
implementation handles that bett
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> I do not know such case. Could you, please, give me an example in lyx 1.5
>> where this occurs?
>
> Open *any* version of lyx, insert anything like graphics, child
> document, external, browse to /var/log/blah, save you lyx file. You
> will see /var/log/b
> I do not know such case. Could you, please, give me an example in lyx 1.5
> where this occurs?
Open *any* version of lyx, insert anything like graphics, child
document, external, browse to /var/log/blah, save you lyx file. You
will see /var/log/blah in your .lyx file.
Bo
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> > Note that novice users do not have to know these. They just click ok
>> > without knowing what they are doing, and the mentioned problem will be
>> > resolved.
>> As JMarc said, this is very dangerous. Much too dangerous.
>
> What is *so dangerous* here?
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> the problems I mentioned in the first message, a good solution to
>> allow me to share different files from the same .lyx document.
>
> Of course, this is 'share the same files from different .lyx document'
Sharing a file for reading is useful and can be
"Bo Peng" <[EMAIL PROTECTED]> writes:
> If the majority of the users keep their files in a subdirectory, my
> feature is not in the way of anything, right? So why do you want to
> enforce such a policy when you do not have to?
You mean like when microsoft thought it would be nice to let people
se
On 4/4/08, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
> > If the majority of the users keep their files in a subdirectory, my
> > feature is not in the way of anything, right? So why do you want to
> > enforce such a policy when you do not have to?
>
>
On Friday 04 April 2008 03:22:51 Bo Peng wrote:
> The examples I gave look exactly like this. The bib and logo
> directories are used by almost all documents in my svn tree. They are
> available on every machine where the tree is checked out. Without
> them, my documents could not compile.
Again
On Thursday 03 April 2008 23:46:20 Bo Peng wrote:
> I am repeating myself the fourth time. We have had these paths in our
> .lyx file since lyx 1.5 (I have learned something from the
> discussions) and nobody has ever said anything. If a user chooses to
> use a file with an absolute path, it is his
> It does make sense to use the "user guide" as an example because we do not
> distribute only the user guide but all the directories, including those where
> the images are. There are no external links in the lyx documentation or else
> our users would not be able to use it.
The examples I g
> Since to me it does not make sense to compromise on the security issue the
> original file location is a bad idea.
I am repeating myself the fourth time. We have had these paths in our
.lyx file since lyx 1.5 (I have learned something from the
discussions) and nobody has ever said anything. I
On Thursday 03 April 2008 20:30:45 Bo Peng wrote:
> You have gone from not fixing the problem to denying the problem. At
> least lyx user's guide refers to ../images/blah.png on every machine
> it is installed.
It does make sense to use the "user guide" as an example because we do not
distribu
> For me an embedded file is a file where the dependencies can be found
> inside. The zip file behaves as directory where all files are inside, with a
> tree structure of directories, if necessary.
>
> Once a file is inside it looses any reference to an external origin.
Please elaborate on h
On Thursday 03 April 2008 20:59:02 Bo Peng wrote:
> Actually, after all these messages, I have not heard a good summary of
> what *you (or Richard)* have in mind, a workable solution that avoids
> the problems I mentioned in the first message, a good solution to
> allow me to share different files
> the problems I mentioned in the first message, a good solution to
> allow me to share different files from the same .lyx document.
Of course, this is 'share the same files from different .lyx document'
Bo
> Yes in the sense that sharing can be done without the reference to the
> initial file path. You are insisting on this feature although there are no
> known examples of this behaviour.
I have given several examples in this thread why access to out of tree
files are needed, and I have shown wh
> > As I have said, this information is relevant on more than one machines.
>
> In the use case that you gave this information is only relevant to you.
You have gone from not fixing the problem to denying the problem. At
least lyx user's guide refers to ../images/blah.png on every machine
it i
> > I want to share the same files across different lyx
> > documents, so I do not want to keep local copies. The link solution
> > was suggested but it does not really work.
>
> As I said it is extremely easy to create a file text like this:
>
> embbeded1 /path/to/embbeded1
> embbeded
On Thursday 03 April 2008 19:50:01 Bo Peng wrote:
> As I have said, this information is relevant on more than one machines.
In the use case that you gave this information is only relevant to you.
Or else we are converting lyx in to a glorified file archive program (and a
lousy one for what i
On Thursday 03 April 2008 19:28:21 Bo Peng wrote:
> > > If I accept that much, I still have to copy files around and modify
> > > each and every copies if it needs to be modified. This is exactly the
> > > thing I would like to avoid.
> >
> > This goal is independent of the next sentence.
>
>
> > However,
> >
> > 1. They can be there, maybe in gray color, to tell users where the
> > files are embedded.
>
> To be useful under your conditions this file needs to be changed. You can
> decide to use another source or during a reorganization its location may
> change.
In the current
On Thursday 03 April 2008 18:05:32 Bo Peng wrote:
> I guess your 'external' means 'files with absolute path'. With the new
> policy that they should not be extracted outside of the document
> directory, these files will always be used so their original path
> information may not be important.
OK
> > If I accept that much, I still have to copy files around and modify
> > each and every copies if it needs to be modified. This is exactly the
> > thing I would like to avoid.
>
> This goal is independent of the next sentence.
Not exactly. I want to share the same files across different ly
On Thursday 03 April 2008 18:22:50 Bo Peng wrote:
> If I accept that much, I still have to copy files around and modify
> each and every copies if it needs to be modified. This is exactly the
> thing I would like to avoid.
This goal is independent of the next sentence.
> Basically, I would like
> If you go that way, yes. But then it's unclear why you really need to know
> the original path, as Jose has been saying. The only possible reason would
> be to update from an external file, and there are other ways to do that,
> outside of LyX. Moreover, note that if all paths are downward from
Bo Peng wrote:
The new problems embedding causes are security problems when these files
are unbundled, as Andre has pointed out. And see my private message for an
even worse scenario than his. As Andre said, here there be dragons, and even
if we could solve these problems, would we be sure we'd
On Thu, Apr 3, 2008 at 11:36 AM, José Matos <[EMAIL PROTECTED]> wrote:
> On Thursday 03 April 2008 16:57:36 Bo Peng wrote:
> > To unbundle, you have to know the original path, right?
>
> Only if it is not external, right? Because you said that we should not
> unbundle external files. You said t
On Thursday 03 April 2008 16:57:36 Bo Peng wrote:
> To unbundle, you have to know the original path, right?
Only if it is not external, right? Because you said that we should not
unbundle external files. You said this before I am just checking.
> If you do not
> want to see these path when ed
> I don't disagree with this I am referring about your update external
> feature, that is the reason for you to retain the original file path, and
> that is what me and other don't want to.
> All the disagreement for my part comes from your proposal to keep the
> original file path.
To unbu
> The new problems embedding causes are security problems when these files
> are unbundled, as Andre has pointed out. And see my private message for an
> even worse scenario than his. As Andre said, here there be dragons, and even
> if we could solve these problems, would we be sure we'd solved th
On Thursday 03 April 2008 16:14:47 Bo Peng wrote:
> Please, what I am proposing includes bundle-mode ending, which can NOT
> be done without a GUI. Even for the easiest case that Richard
> proposes, if you even want users to choose which files to embed, you
> will need a GUI.
I don't disagree wi
Bo Peng wrote:
The only reason not to require this is because
you'd like to be able to keep your files elsewhere in your tree. I'm
prepared to allow that this could be convenient. But I don't see any reason
you really have to do that.
Now, the critical question is why someone would like to
> With all the due respect Bo, I know that you are competent python
> programmer. What you are proposing can be done in python without ever using
> the lyx gui.
Please, what I am proposing includes bundle-mode ending, which can NOT
be done without a GUI. Even for the easiest case that Richard
> > Note that novice users do not have to know these. They just click ok
> > without knowing what they are doing, and the mentioned problem will be
> > resolved.
> >
> >
> >
> As JMarc said, this is very dangerous. Much too dangerous.
What is *so dangerous* here? The result is that such files wil
> > I forgot to mention one important trick: if the files are there so
> > there is no need to overwrite, unbundling would succeed and they do
> > not have to be unbundled to the document directory. This is because we
> > compare file checksum before we extract.
> >
> So if the files are there and
On Thursday 03 April 2008 14:18:01 Bo Peng wrote:
> > I guess I don't see this, quite. Sure, you can specify the the distant
> > file when you choose it, but once it is embedded, the distant file has
> > nothing to do with it. It can only be extracted to a subdirectory (if
> > you're still doing a
Bo Peng wrote:
I guess I don't see this, quite. Sure, you can specify the the distant file
when you choose it, but once it is embedded, the distant file has nothing to
do with it. It can only be extracted to a subdirectory (if you're still
doing a general unbundling, as opposed to selective unbu
John McCabe-Dansted wrote:
On 4/3/08, Bo Peng <[EMAIL PROTECTED]> wrote:
> an executive summary (without rhetorics) would be helpful for bystanders
> to also chime in...
The simple solution, which is essentially Richard's proposal, is that:
An even simpler solution is a "Collect f
José Matos wrote:
On Thursday 03 April 2008 03:24:04 Bo Peng wrote:
I guess this solves all the problem. Any objection?
No.
I have one remark though, with your proposal the absolute path of the
embedded files is need no longer. In that case I propose to drop it. As I
said in ano
Bo Peng wrote:
I'd simply drop that feature. There is no proper solution possible.
Actually, when I think about it...
Suppose I bundle a file with relative path
"../../../../../../../../../etc/passwd"
and open that file with root permissions in LyX.
If you sys admin does this, you
Jean-Marc Lasgouttes wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
I'd simply drop that feature. There is no proper solution possible.
+1
indeed
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Note that novice users do not have to know these. They just click ok
> without knowing what they are doing, and the mentioned problem will be
> resolved.
No.
We do not want to encourage people to 'click OK without knowing what
it means'. This attitude is d
> I guess I don't see this, quite. Sure, you can specify the the distant file
> when you choose it, but once it is embedded, the distant file has nothing to
> do with it. It can only be extracted to a subdirectory (if you're still
> doing a general unbundling, as opposed to selective unbundling, a
> I am not sure what happens on windows but on linux if you compress a file
> with an absolute path the archive program will drop the first / and extract
> the resulting files with a relative path. I think that this is sane and this
> what I would like lyx to do. Does that makes sense to you?
On 4/3/08, Bo Peng <[EMAIL PROTECTED]> wrote:
> >
> > an executive summary (without rhetorics) would be helpful for bystanders
> > to also chime in...
>
> The simple solution, which is essentially Richard's proposal, is that:
An even simpler solution is a "Collect for output" option like Quark
On Thursday 03 April 2008 03:24:04 Bo Peng wrote:
> I guess this solves all the problem. Any objection?
No.
I have one remark though, with your proposal the absolute path of the
embedded files is need no longer. In that case I propose to drop it. As I
said in another thread if you want to k
Andre Poenitz <[EMAIL PROTECTED]> writes:
> I'd simply drop that feature. There is no proper solution possible.
+1
JMarc
On Wed, Apr 02, 2008 at 09:24:04PM -0500, Bo Peng wrote:
> > I'd simply drop that feature. There is no proper solution possible.
> >
> > Actually, when I think about it...
> > Suppose I bundle a file with relative path
> >
> > "../../../../../../../../../etc/passwd"
> >
> > and open that file
> Surely we can know better by parsing the latex output or else we are giving a
> free ride to all kind of files. That will be difficult to get rid later
> because of previous usage.
It is not that easy because you will have to run latex to get the log
file, which is not always the case. Also,
> > d1) never allow explicit embedding of anything above the bundle file.
> > There be dragons.
> >
> This is precisely the suggestion I made a while ago. And IF you do this,
> then every other problem Bo mentioned with the "transparent embedding"
> solution can be solved. I won't detail the solut
> I'd simply drop that feature. There is no proper solution possible.
>
> Actually, when I think about it...
> Suppose I bundle a file with relative path
>
> "../../../../../../../../../etc/passwd"
>
> and open that file with root permissions in LyX.
If you sys admin does this, you should im
Andre Poenitz wrote:
The current implementation allows you to embed *any* file, relative or
absolute. Once they are embedded, they should work in the embedded
mode. If you unbundle them under the same system, they went back to
their original locations. (Note that, because these out-of-tree files
Andre Poenitz wrote:
On Wed, Apr 02, 2008 at 11:23:33PM +0100, José Matos wrote:
On Wednesday 02 April 2008 22:43:57 Bo Peng wrote:
Actually, I know only one limitation (assuming others are bugs), and
this limitation exists from lyx 0.1. I mean, you simply cannot use a
file with absolut
On Wed, Apr 02, 2008 at 11:23:33PM +0100, José Matos wrote:
> On Wednesday 02 April 2008 22:43:57 Bo Peng wrote:
> > Actually, I know only one limitation (assuming others are bugs), and
> > this limitation exists from lyx 0.1. I mean, you simply cannot use a
> > file with absolute-path on different
On Wed, Apr 02, 2008 at 05:01:29PM -0500, Bo Peng wrote:
> > >
> > > _This_ surely won't ever work outside controlled enviroments.
> > >
> > >
> > >
> > Yes, I think that's precisely what he's trying to do. He wants to be able
> > to have a single (say) image file that is embedded in multiple LyX
On Wed, Apr 2, 2008 at 5:23 PM, José Matos <[EMAIL PROTECTED]> wrote:
> On Wednesday 02 April 2008 22:43:57 Bo Peng wrote:
> > Actually, I know only one limitation (assuming others are bugs), and
> > this limitation exists from lyx 0.1. I mean, you simply cannot use a
> > file with absolute-path
On Wednesday 02 April 2008 22:43:57 Bo Peng wrote:
> Actually, I know only one limitation (assuming others are bugs), and
> this limitation exists from lyx 0.1. I mean, you simply cannot use a
> file with absolute-path on different systems.
Actually you are referring to version 1.5 the first ver
On Wednesday 02 April 2008 22:49:26 Bo Peng wrote:
> > First I note that the first alpha should not wait for this to be
> > finished or the goals more or less set. I agree with you if the target is
> > the first beta.
>
> By alpha, we mean the major features are almost done, and we will turn
> to
Bo Peng wrote:
_This_ surely won't ever work outside controlled enviroments.
Yes, I think that's precisely what he's trying to do. He wants to be able
to have a single (say) image file that is embedded in multiple LyX files,
referenced by absolute path, and have it be packed and unpac
> >
> > _This_ surely won't ever work outside controlled enviroments.
> >
> >
> >
> Yes, I think that's precisely what he's trying to do. He wants to be able
> to have a single (say) image file that is embedded in multiple LyX files,
> referenced by absolute path, and have it be packed and unpacke
> First I note that the first alpha should not wait for this to be finished or
> the goals more or less set. I agree with you if the target is the first beta.
By alpha, we mean the major features are almost done, and we will turn
to bug-fixing mode. Totally rewrite embedding after alpha one doe
Andre Poenitz wrote:
On Wed, Apr 02, 2008 at 03:52:41PM -0500, Bo Peng wrote:
I think it would be solvable with the "homegrown links" I just
suggested.
By 'link's, you actually do not embed the files themselves, and your
.lyx file will not compile on a system without them.
Ri
> > 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.
> >
> >
> >
> And here's my view: Because this is so simple, becau
On Wed, Apr 02, 2008 at 03:52:41PM -0500, Bo Peng wrote:
> > I think it would be solvable with the "homegrown links" I just
> > suggested.
>
> By 'link's, you actually do not embed the files themselves, and your
> .lyx file will not compile on a system without them.
Right. That's the point.
Bu
On Wednesday 02 April 2008 18:11:56 Bo Peng wrote:
> Hi, Richard,
>
> Are you still trying to push your ideas? I have pointed out a few
> flaws in your design and your solutions are not really satisfactory. I
> think we need to fix the embedding design before alpha one is
> released.
First I not
Bo Peng wrote:
an executive summary (without rhetorics) would be helpful for bystanders
to also chime in...
And just to clarify---I'm not pushing any particular view here; I'm just
trying to imagine how users (including this potential user) will
react---let me just add a few comments. I'l
> I think it would be solvable with the "homegrown links" I just
> suggested.
By 'link's, you actually do not embed the files themselves, and your
.lyx file will not compile on a system without them.
Bo
Andre Poenitz wrote:
On Wed, Apr 02, 2008 at 09:59:01PM +0200, Juergen Spitzmueller wrote:
Bo Peng wrote:
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 fil
On Wed, Apr 02, 2008 at 09:59:01PM +0200, Juergen Spitzmueller wrote:
> Bo Peng wrote:
>
> > 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 extr
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 automati
> Nothing has yet been done, so far as I know, about other affected insets,
> but the problem should be solvable in much the same way. I guess it would
> help me to know which insets are affected.
Currently, embedding-aware insets are InsetBibtex, InsetGraphics,
InsetInclude and InsetExternal.
B
Bo Peng wrote:
> Yes. Richard has solved them but I am not sure if he has committed his
> patch. The patch itself is easy to fix but we have a long friendly
> discussion on how to fix it.
OK. Great.
Jürgen
Juergen Spitzmueller wrote:
Bo Peng wrote:
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
> Is the other problem people are unhappy about solved? I.e., the problem
> where files without paths that are managed by TeX's kpathsea system (and
> stored in the texmf tree) were erroneosuly saved as being in the document
> (relative) path (bug 4649)?
Yes. Richard has solved them but I am n
Bo Peng wrote:
> 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/
>
> an executive summary (without rhetorics) would be helpful for bystanders
> to also chime in...
OK. Here it is.
The goal of the embedding feature is to ease the difficulties in
sharing .lyx documents, especially those with customized .layout and
.cls files such as theses. The current situatio
> I am not convinced about the need to ease the unbundling.
I will explain my design in another thread, where a summary is requested.
Bo
Bo Peng wrote:
Hi, Richard,
Are you still trying to push your ideas? I have pointed out a few
flaws in your design and your solutions are not really satisfactory. I
think we need to fix the embedding design before alpha one is
released.
an executive summary (without rhetorics) would be helpful
On Tuesday 01 April 2008 20:01:29 Bo Peng wrote:
> > Bo one question, out of curiosity, do you know of any other program that
> > does what you are proposing (working with external files)?
>
> No. :-)
>
> The embedding feature is unique in its bunble/unbundle reversibility.
> In the word/ooffice w
Hi, Richard,
Are you still trying to push your ideas? I have pointed out a few
flaws in your design and your solutions are not really satisfactory. I
think we need to fix the embedding design before alpha one is
released.
Cheers,
Bo
> Bo one question, out of curiosity, do you know of any other program that does
> what you are proposing (working with external files)?
No. :-)
The embedding feature is unique in its bunble/unbundle reversibility.
In the word/ooffice world, embedded objects are embedded, and there
are limited o
On Tuesday 01 April 2008 19:10:13 Bo Peng wrote:
> Given that a lot of work has been done to make it work, I propose that
> we add an option ([ ] bundle files not in or under the document
> directory) that is by default disabled. In this way, we at least allow
> power users to emded such files.
Bo
1 - 100 of 115 matches
Mail list logo
