Andre Poenitz wrote:
On Sun, May 11, 2008 at 12:24:03PM -0400, rgheck wrote:
rgheck wrote:
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
On Sun, May 11, 2008 at 12:24:03PM -0400, rgheck wrote:
rgheck wrote:
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
Andre Poenitz wrote:
On Sun, May 11, 2008 at 12:24:03PM -0400, rgheck wrote:
rgheck wrote:
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
On Sun, May 11, 2008 at 12:24:03PM -0400, rgheck wrote:
> rgheck wrote:
>>> 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
Bo Peng wrote:
On Mon, May 12, 2008 at 6:43 PM, Bo Peng [EMAIL PROTECTED] wrote:
In that sense, the
reversibility problem is yours, not mine.
I'm perplexed about this, since I don't have any such problem.
Let me try it the last time.
Let me try to summarize the
I like Richard's solution better. Having a zip based solution means that you
can 'unbundle' from the command line even without LyX, the base64 solution
is more complex.
I would favour a simple bundling / unbundling where everything is bundled
and everything is unbundled but add the possibility
Charles de Miramon [EMAIL PROTECTED] writes:
I like Richard's solution better. Having a zip based solution means that you
can 'unbundle' from the command line even without LyX, the base64 solution
is more complex.
Yes, a file that can be read/handled without LyX is more powerful. We
could try
Bo Peng wrote:
Working like OOo does not mean it is a good way for latex because we
routinely work with external files. If you do not want users to mess
around the filename.lyxdir directory, I would suggest that you always
put this directory under the temporary directory. If you do allow
users
Many users already maintain their own directory underneath the document
directory. They can of course continue to do so.
They cannot. Once the document is turned to the 'bundled mode', users
have to depend on 'update from external' to make their changes to
these files available to lyx. What
Yes, a file that can be read/handled without LyX is more powerful. We
could try to use MIME format for LyX files, but it may become
unpleasant to handle.
Sure, 'may become unpleasant' when you try to handle .lyx file without
lyx, but the problems I have mentioned may make everyday lyx usage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
It does sound like an advantage. It seems more in accord with the way
Lyx has traditionally worked, to me.
Bo Peng wrote:
| On the other hand, the file format in my proposal is still plain text.
| For many other operations such as search and
Bo Peng [EMAIL PROTECTED] writes:
Sure, 'may become unpleasant' when you try to handle .lyx file without
lyx, but the problems I have mentioned may make everyday lyx usage
unpleasant. Which one is more important?
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know
I like Richard's solution better. Having a zip based solution means that you
can 'unbundle' from the command line even without LyX, the base64 solution
is more complex.
On the other hand, the file format in my proposal is still plain text.
For many other operations such as search and
Bo Peng wrote:
On the other hand, the file format in my proposal is still plain text.
For many other operations such as search and replace, you do not have
to unzip. I consider this as an advantage.
You have got a point. But the mix of text and base64 which is what is done
in rtf, if I'm
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
We should choose a file format that
Bo Peng wrote:
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
We should choose a
Jean-Marc Lasgouttes wrote:
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
This is non issue IMHO. I really don't think users that use svn should
be interested in this bundle/embedded business. It's
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
This is non issue IMHO. I really don't think users that use svn should be
interested in this bundle/embedded business. It's rather the opposite, only
Bo's embedding proposal:
1) This is about embedding files directly in the '.lyx' file encoded with
base64.
2) Each and every external file can be embedded individually.
Right. Note that 3, 4 and 5 are not part of the proposal at this
stage. 1 and 2 are enough to achieve my goal, and 3, 4,
Bo Peng wrote:
My solution achieves full reversibility without security problem.
This is impossible. If LyX can write arbitrary embedded files to
arbitrary locations in the file system, then that is a massive security
problem. If that isn't clear, then, well, that's unfortunate, but I have
Bo Peng wrote:
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
This is non issue IMHO. I really don't think users that use svn should be
interested in this bundle/embedded business. It's rather the
Bo Peng wrote:
My solution achieves full reversibility without security problem.
This is impossible. If LyX can write arbitrary embedded files to arbitrary
locations in the file system, then that is a massive security problem. If
that isn't clear, then, well, that's unfortunate,
Well, then you don't have full reversibility. OK.
Depending on how you define it. As I have said, my approach does not
have the reversibility problem because there is no bundled mode. If
you really want to 'bundle all' and 'unbundled all', a feature I might
not even offer, my approach allows
Abdelrazak Younes wrote:
Bo Peng wrote:
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
Richard Heck wrote:
Abdelrazak Younes wrote:
Bo Peng wrote:
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents
end up
being in base64, all the interested of
auto-update would be interesting.
I have heard the 'URL' idea, and now the auto-update idea. I am
interested to know how these can make the bundled mode work better.
Please note that my approach needs no change of how users work with
external files. Also, these will make the 'simple' idea of
Well, maybe you're mirroring the original directory structure, in a way
like chroot. But you're not recreating it. And I don't see the advantage
of doing that myself.
This is Enrico's idea. The lyx file may be put several levels under
the new directory so that the original
My solution achieves full reversibility without security problem.
This is impossible. If LyX can write arbitrary embedded files to arbitrary
locations in the file system, then that is a massive security problem. If
that isn't clear, then, well, that's unfortunate, but I have already wasted
Bo Peng wrote:
File-Export-LyX with extracted files. A Python script will be
called to extract a .lyx file to a new directory (e.g.
filename.extracted under the document directory), and arrange files in
their original layout.
By full reversibility, I take it you mean that you can
On Tue, May 13, 2008 at 12:23 PM, Bo Peng [EMAIL PROTECTED] wrote:
auto-update would be interesting.
By the way, the 'auto-update' idea was mine. :-) I proposed it before
and was convinced by Jose (and JMarc?) that it is too confusing to
users.
Bo
Bo Peng wrote:
Well, maybe you're mirroring the original directory structure, in a way
like chroot. But you're not recreating it. And I don't see the advantage
of doing that myself.
This is Enrico's idea. The lyx file may be put several levels under
the new directory so that the original
Bo Peng wrote:
auto-update would be interesting.
I have heard the 'URL' idea, and now the auto-update idea. I am
interested to know how these can make the bundled mode work better.
Please note that my approach needs no change of how users work with
external files. Also, these will make
Well, if that's the idea, then I'm with Edwin (was it?) who proposed just
using a python script for this kind of purpose.
It was Enrico's idea.
If you have read my response to Enrico's proposal, you should have
known that I would support his proposal, if only my goal is to provide
a way to
Bo Peng wrote:
On Mon, May 12, 2008 at 6:43 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
In that sense, the
> > reversibility problem is yours, not mine.
> >
> I'm perplexed about this, since I don't have any such problem.
Let me try it the last time.
Let me try to
I like Richard's solution better. Having a zip based solution means that you
can 'unbundle' from the command line even without LyX, the base64 solution
is more complex.
I would favour a simple bundling / unbundling where everything is bundled
and everything is unbundled but add the possibility
Charles de Miramon <[EMAIL PROTECTED]> writes:
> I like Richard's solution better. Having a zip based solution means that you
> can 'unbundle' from the command line even without LyX, the base64 solution
> is more complex.
Yes, a file that can be read/handled without LyX is more powerful. We
Bo Peng wrote:
Working like OOo does not mean it is a good way for latex because we
routinely work with external files. If you do not want users to mess
around the filename.lyxdir directory, I would suggest that you always
put this directory under the temporary directory. If you do allow
users
> Many users already maintain their own directory underneath the document
> directory. They can of course continue to do so.
They cannot. Once the document is turned to the 'bundled mode', users
have to depend on 'update from external' to make their changes to
these files available to lyx. What
> Yes, a file that can be read/handled without LyX is more powerful. We
> could try to use MIME format for LyX files, but it may become
> unpleasant to handle.
Sure, 'may become unpleasant' when you try to handle .lyx file without
lyx, but the problems I have mentioned may make everyday lyx
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
It does sound like an advantage. It seems more in accord with the way
Lyx has traditionally worked, to me.
Bo Peng wrote:
| On the other hand, the file format in my proposal is still plain text.
| For many other operations such as search and
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Sure, 'may become unpleasant' when you try to handle .lyx file without
> lyx, but the problems I have mentioned may make everyday lyx usage
> unpleasant. Which one is more important?
If I think of openoffice zip file versus ms office
filesystem-in-a-file,
> I like Richard's solution better. Having a zip based solution means that you
> can 'unbundle' from the command line even without LyX, the base64 solution
> is more complex.
On the other hand, the file format in my proposal is still plain text.
For many other operations such as search and
Bo Peng wrote:
> On the other hand, the file format in my proposal is still plain text.
> For many other operations such as search and replace, you do not have
> to unzip. I consider this as an advantage.
You have got a point. But the mix of text and base64 which is what is done
in rtf, if I'm
> If I think of openoffice zip file versus ms office
> filesystem-in-a-file, I know which one is easier to tinker with.
> Base64 may seem nice because it is text, but if child documents end up
> being in base64, all the interested of svn is lost, for example.
We should choose a file format
Bo Peng wrote:
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
We should choose a
Jean-Marc Lasgouttes wrote:
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
This is non issue IMHO. I really don't think users that use svn should
be interested in this bundle/embedded business. It's
> > Base64 may seem nice because it is text, but if child documents end up
> > being in base64, all the interested of svn is lost, for example.
> >
> >
> This is non issue IMHO. I really don't think users that use svn should be
> interested in this bundle/embedded business. It's rather the
> Bo's embedding proposal:
> 1) This is about embedding files directly in the '.lyx' file encoded with
> base64.
> 2) Each and every external file can be embedded individually.
Right. Note that 3, 4 and 5 are not part of the proposal at this
stage. 1 and 2 are enough to achieve my goal, and 3,
Bo Peng wrote:
My solution achieves full reversibility without security problem.
This is impossible. If LyX can write arbitrary embedded files to
arbitrary locations in the file system, then that is a massive security
problem. If that isn't clear, then, well, that's unfortunate, but I have
Bo Peng wrote:
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
This is non issue IMHO. I really don't think users that use svn should be
interested in this bundle/embedded business. It's rather the
Bo Peng wrote:
My solution achieves full reversibility without security problem.
This is impossible. If LyX can write arbitrary embedded files to arbitrary
locations in the file system, then that is a massive security problem. If
that isn't clear, then, well, that's unfortunate,
> Well, then you don't have "full reversibility". OK.
Depending on how you define it. As I have said, my approach does not
have the reversibility problem because there is no bundled mode. If
you really want to 'bundle all' and 'unbundled all', a feature I might
not even offer, my approach allows
Abdelrazak Younes wrote:
Bo Peng wrote:
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
Richard Heck wrote:
Abdelrazak Younes wrote:
Bo Peng wrote:
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents
end up
being in base64, all the interested of
> "auto-update" would be interesting.
>
I have heard the 'URL' idea, and now the auto-update idea. I am
interested to know how these can make the bundled mode work better.
Please note that my approach needs no change of how users work with
external files. Also, these will make the 'simple' idea
> Well, maybe you're mirroring the original directory structure, in a way
> like chroot. But you're not "recreating" it. And I don't see the advantage
> of doing that myself.
This is Enrico's idea. The lyx file may be put several levels under
the new directory so that the original
> > My solution achieves full reversibility without security problem.
> This is impossible. If LyX can write arbitrary embedded files to arbitrary
> locations in the file system, then that is a massive security problem. If
> that isn't clear, then, well, that's unfortunate, but I have already
Bo Peng wrote:
"File->Export->LyX with extracted files". A Python script will be
called to extract a .lyx file to a new directory (e.g.
filename.extracted under the document directory), and arrange files in
their original layout.
By "full reversibility", I take it you mean that you can
On Tue, May 13, 2008 at 12:23 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
> > "auto-update" would be interesting.
By the way, the 'auto-update' idea was mine. :-) I proposed it before
and was convinced by Jose (and JMarc?) that it is too confusing to
users.
Bo
Bo Peng wrote:
Well, maybe you're mirroring the original directory structure, in a way
like chroot. But you're not "recreating" it. And I don't see the advantage
of doing that myself.
This is Enrico's idea. The lyx file may be put several levels under
the new directory so that the
Bo Peng wrote:
"auto-update" would be interesting.
I have heard the 'URL' idea, and now the auto-update idea. I am
interested to know how these can make the bundled mode work better.
Please note that my approach needs no change of how users work with
external files. Also, these will
> Well, if that's the idea, then I'm with Edwin (was it?) who proposed just
> using a python script for this kind of purpose.
It was Enrico's idea.
If you have read my response to Enrico's proposal, you should have
known that I would support his proposal, if only my goal is to provide
a way to
Bo Peng wrote:
This makes unbundling, namely extracting all embedded files, almost
irrelevant. But I do agree that unbundling is a good feature to have.
Because unbundling, under my design, will change .lyx file in an
intrusive way, I proposed to make it something similar to
File-Export-LyX with
Bo Peng wrote:
This discussion would also involve the words session-based alternative.
And I should have added: I thought we had agreed that we will not implement
any form of reversibility. It's what leads to the really bad security
problems.
Technically speaking, we are aiming
File-Export-LyX with extracted files. A Python script will be
called to extract a .lyx file to a new directory (e.g.
filename.extracted under the document directory), and arrange files in
their original layout.
By full reversibility, I take it you mean that you can completely undo
the
In that sense, the
reversibility problem is yours, not mine.
I'm perplexed about this, since I don't have any such problem.
Your bundle / bundle is not reversible. When a user turns on
bundled-mode on an existing document, his external files are copied to
filename.lyxdir/blah. When he
On Mon, May 12, 2008 at 6:43 PM, Bo Peng [EMAIL PROTECTED] wrote:
In that sense, the
reversibility problem is yours, not mine.
I'm perplexed about this, since I don't have any such problem.
Let me try it the last time.
My design goal is to 'create a lyx format with embedded files
Bo Peng wrote:
This makes unbundling, namely extracting all embedded files, almost
irrelevant. But I do agree that unbundling is a good feature to have.
Because unbundling, under my design, will change .lyx file in an
intrusive way, I proposed to make it something similar to
"File->Export->LyX
Bo Peng wrote:
This discussion would also involve the words "session-based alternative".
And I should have added: I thought we had agreed that we will not implement
any form of reversibility. It's what leads to the really bad security
problems.
Technically speaking, we are aiming
> > "File->Export->LyX with extracted files". A Python script will be
> > called to extract a .lyx file to a new directory (e.g.
> > filename.extracted under the document directory), and arrange files in
> > their original layout.
> >
> By "full reversibility", I take it you mean that you can
>> In that sense, the
> > reversibility problem is yours, not mine.
> >
> I'm perplexed about this, since I don't have any such problem.
Your bundle / bundle is not reversible. When a user turns on
bundled-mode on an existing document, his external files are copied to
filename.lyxdir/blah. When
On Mon, May 12, 2008 at 6:43 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
> >> In that sense, the
> > > reversibility problem is yours, not mine.
> > >
> > I'm perplexed about this, since I don't have any such problem.
Let me try it the last time.
My design goal is to 'create a lyx format with
Bo Peng wrote:
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
rgheck wrote:
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
This discussion would also involve the words session-based alternative.
And I should have added: I thought we had agreed that we will not implement
any form of reversibility. It's what leads to the really bad security
problems.
Technically speaking, we are aiming at different goals. I have
This is all more or less correct, but bundling is separate from compressing.
Bundled mode doesn't involve any file format change, except for a buffer
parameter flag (\bundled). It is important to understand this, as many of
the remarks made below have to do with the *.lyz business. This has
Bo Peng wrote:
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
rgheck wrote:
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
>> This discussion would also involve the words "session-based alternative".
>>
> And I should have added: I thought we had agreed that we will not implement
> any form of reversibility. It's what leads to the really bad security
> problems.
Technically speaking, we are aiming at different goals.
> This is all more or less correct, but bundling is separate from compressing.
> Bundled mode doesn't involve any file format change, except for a buffer
> parameter flag (\bundled). It is important to understand this, as many of
> the remarks made below have to do with the "*.lyz" business. This
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
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
82 matches
Mail list logo
