> Why not using LyX.Embed.X for the drive letter under windows?
The logic in EmbeddedFIle::set() should be carefully examined. It
works like this now,
1. When a file is created, for example,
document path: /home/bpeng/doc/file.lyx
embedded file: /home/bpeng/figures/figure.png
Its relative
> I understand the path problem, but not why LyX crashes. When an embedded file
> could not be found (no
> matter if the path or what ever is the reason), LyX should display the error
> message as it already
> does, but then not crash.
In the implementation, I intentionally assumes the availabil
> The problem is clear: there is no unique representation of absolute
> path under different OS.
I understand the path problem, but not why LyX crashes. When an embedded file could not be found (no
matter if the path or what ever is the reason), LyX should display the error message as it already
Bo Peng wrote:
In the end, Joost's suggestion might be the only solution.
Joost's solution has its own features/problems. For example, when I
insert the same file twice, the current solution consider them as the
same file (both external and inzip). However, using UUID as inzip
filename, they wi
Bo Peng wrote:
The problem is clear: there is no unique representation of absolute
path under different OS. The absolute file in the test lyx file is
/home/bpeng/blah and its inzip name is LyX.Embed.Abs/home/bpeng/blah.
Under windows, the file is considered as
c:/home/bpeng/blah and its inzip na
> In the end, Joost's suggestion might be the only solution.
Joost's solution has its own features/problems. For example, when I
insert the same file twice, the current solution consider them as the
same file (both external and inzip). However, using UUID as inzip
filename, they will be different.
The problem is clear: there is no unique representation of absolute
path under different OS. The absolute file in the test lyx file is
/home/bpeng/blah and its inzip name is LyX.Embed.Abs/home/bpeng/blah.
Under windows, the file is considered as
c:/home/bpeng/blah and its inzip name is
LyX.embed.A
On Jan 8, 2008 5:38 PM, Uwe Stöhr <[EMAIL PROTECTED]> wrote:
> Bo Peng schrieb:
>
> > Did you see this right after lyx opens the file?
>
> Yes.
OK, I am building a windows version.
Bo
Bo Peng schrieb:
Did you see this right after lyx opens the file?
Yes.
Uwe
> I get:
>
> Failed to embed file C:/usr/local/share/icons/hicolor/48x48/apps/poedit.png.
> Please check whether this file exists and is readable.
>
> Because I don't have the poedit.png.
> But then LyX crashes!
I know absolute path would lead to problems...
Did you see this right after lyx opens
> I have uploaded a test file to
> http://www.lyx.org/~bpeng/test.lyx, which has several embedded insets.
> Please play with it and see if you like how embedding is done
> now.
I get:
Failed to embed file C:/usr/local/share/icons/hicolor/48x48/apps/poedit.png.
Please check whether this file exis
> Maybe this has been discussed before but why don't we standardize on a
> .zlyx or .lyz extension?
If you are talking about blocking, extension does not matter.
In general, the problem of .lyz is that there is no easy logic for
'save' and 'save as' if two file extensions are used.
Bo
Bo Peng wrote:
Dear all,
With my last several commits, I have added embedding support for
InsetGraphics, InsetInclude, InsetExternal and InsetBibtex (any
more??). I have uploaded a test file to
http://www.lyx.org/~bpeng/test.lyx, which has several embedded insets.
Please play with it and see if
On Monday 04 December 2000 18:45, Lars Gullik Bjønnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
> | On Mon, Dec 04, 2000 at 03:56:53PM +0100, Lars Gullik Bjønnes wrote:
> | > Angus Leeming <[EMAIL PROTECTED]> writes:
> | > | This is dying in Buffer::isLatex()
> | >
> | > Are you sure that in
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Dec 04, 2000 at 03:56:53PM +0100, Lars Gullik Bjønnes wrote:
| > Angus Leeming <[EMAIL PROTECTED]> writes:
| >
| > | This is dying in Buffer::isLatex()
| >
| > Are you sure that inlining is not playing tricks on you?
| >
| > Seems almost liek is
On Mon, Dec 04, 2000 at 03:56:53PM +0100, Lars Gullik Bj&resh;nnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | This is dying in Buffer::isLatex()
>
> Are you sure that inlining is not playing tricks on you?
>
> Seems almost liek isLatex is beeing called on a buffer that has just
>
On Monday 04 December 2000 14:56, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | This is dying in Buffer::isLatex()
>
> Are you sure that inlining is not playing tricks on you?
>
> Seems almost liek isLatex is beeing called on a buffer that has just
> been deleted...
B
Angus Leeming <[EMAIL PROTECTED]> writes:
| This is dying in Buffer::isLatex()
Are you sure that inlining is not playing tricks on you?
Seems almost liek isLatex is beeing called on a buffer that has just
been deleted...
Lgb
This is dying in Buffer::isLatex()
bool Buffer::isLatex() const
{
return textclasslist.TextClass(params.textclass).outputType() == LATEX;
}
This hack works:
bool Buffer::isLatex() const
{
return true;
}
All displays correctly.
This fails on return:
bool Buffer::isLatex() const
19 matches
Mail list logo
