Jean-Marc Lasgouttes wrote:
Juergen, OK for branch?
Yes.
Jürgen
rgheck wrote:
See if r25508 works for you.
It does. Thanks indeed.
Jürgen
Bo Peng [EMAIL PROTECTED] writes:
This is why the paragraph should store the name of the layout, and the
pointer should just be a cache (that gets populated on demand, maybe).
There is of course a memory overhead, but this has to be evaluated.
I do not know, these changes might be too big
rgheck [EMAIL PROTECTED] writes:
I think maybe you're extending the wrong thing, then. The extended
layouts should go into the DocumentClass object associated with the
Buffer, rather than into the LayoutFile object. I think that will
just work.
Very interesting indeed. Thanks.
JMarc
killermike wrote:
Abdelrazak Younes wrote:
Hi,
Question to image conversion experts:
While I agree that ImageMagick is required for more specialized
formats(*), we support already most common raster image formats
thanks to Qt, without the need for ImageMagick; for ps/pdf/eps
conversion to
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
Hi,
Question to image conversion experts:
While I agree that ImageMagick is required for more specialized
formats(*), we support already most common raster image formats thanks
to Qt, without the need for ImageMagick;
Uwe Stöhr wrote:
While I agree that ImageMagick is required for more specialized
formats(*), we support already
most common raster image formats thanks to Qt, without the need for
ImageMagick; for ps/pdf/eps
conversion to png, we should just use ghostscript directly. Why you
might ask?
Abdelrazak Younes [EMAIL PROTECTED] writes:
And there is nothing that really forces us to install or not IM. It is
just a converter among others (or it should).
It is not, it is hardcoded in the code which calls 'convertDefault.py'
which itself calls 'convert'. I am not sure LyX would work
[EMAIL PROTECTED] writes:
+ int length = params_.length.inBP();
+ if (length 0)
+ length = -1 * length;
+ dim.wid = length;
What about using abs()?
JMarc
Abdelrazak Younes schrieb:
If you talk about screen effects then we already use Qt. But I didn't
know that IM was used for preparing the images before latex compilation.
Yes we use IM for that.
regards Uwe
[EMAIL PROTECTED] writes:
Author: jamatos
Date: Fri May 30 16:43:42 2008
New Revision: 25012
URL: http://www.lyx.org/trac/changeset/25012
Log:
Reduce the news of stable versions other than the first to the highlights.
Juergen, can I import this simplified version of NEWS to 1.5.x? I
think
Hi,
I would like to change the version from 1.6.0svn to 1.6.0beta4 on
trunk.
After that I would like to see only fixes for compilation and building issues
before the versions is released and the trunk goes back to general bug fixes
again.
Is there any bug fix that you are
Jean-Marc Lasgouttes wrote:
Juergen, can I import this simplified version of NEWS to 1.5.x? I
think a too long NEWS file is not useful.
Yes, OK.
If needed, I could add for
each version an URL to the full announcement.
I don't think this is necessary.
Thanks,
Jürgen
Jean-Marc Lasgouttes wrote:
What about using abs()?
Thanks. I knew there would be some std function %-|
Jürgen
Attached is an updated patch, not final yet.
1. When you open a document with unknown textclass, a default
textclass is added with only the standard layout.
2. All unknown layouts will be displayed as layout (unknown)
3. Edit and save will not lead to loss of data.
4. You can apply other
On Wed, Jul 9, 2008 at 9:03 AM, Jürgen Spitzmüller
[EMAIL PROTECTED] wrote:
Nothing really crucial, but I'd like to have the attached patch at least in
1.6.0, since these different encodings with undescriptive names (utf8 vs.
UTF8 vs. utf8x and EUC-JP vs. EUC-JP-pLaTEX etc.) really confuse
Bo Peng [EMAIL PROTECTED] writes:
Attached is an updated patch, not final yet.
1. When you open a document with unknown textclass, a default
textclass is added with only the standard layout.
Why not article as we always have done?
JMarc
Jürgen Spitzmüller wrote:
The attached patches change the behaviour. My testing didn't show any
differences in the outtput, but I think it is to be expected that the
output of some documents might change.
Actually, there is an unwanted change in the output due toi this patch:
Paragraphs
Bo Peng wrote:
The more Pythonic way is if not line.startswith('Encoding')
Ah, thanks.
SConstruct needs to be aware of the new lyx_pot call and its
dependence on lib/encoding,
Yes, I've done that, but forgot to diff it.
something like
1. When you open a document with unknown textclass, a default
textclass is added with only the standard layout.
Why not article as we always have done?
Because when I save the document, I want to keep the original layout
name so that when the right layout file comes around, I can open the
Bo Peng [EMAIL PROTECTED] writes:
1. When you open a document with unknown textclass, a default
textclass is added with only the standard layout.
Why not article as we always have done?
Because when I save the document, I want to keep the original layout
name so that when the right layout
That would do the trick.
I will add it.
Other than the document-dependent unknown layouts problem (extend
DocumentClass rather than LayoutFile as Richard suggested), I am not
sure whether or not pasted text should bring unknown layouts to a
document. These layouts will not cause any trouble
Bo Peng [EMAIL PROTECTED] writes:
Other than the document-dependent unknown layouts problem (extend
DocumentClass rather than LayoutFile as Richard suggested), I am not
sure whether or not pasted text should bring unknown layouts to a
document.
I think they should. This simplifies the code
Jürgen Spitzmüller [EMAIL PROTECTED] writes:
Jean-Marc Lasgouttes wrote:
Juergen, can I import this simplified version of NEWS to 1.5.x? I
think a too long NEWS file is not useful.
Yes, OK.
Done.
JMarc
Jean-Marc Lasgouttes wrote:
Yes, OK.
Done.
Thank you.
Jürgen
On Wed, Jul 09, 2008 at 10:31:17AM -, [EMAIL PROTECTED] wrote:
Author: spitz
Date: Wed Jul 9 12:31:16 2008
New Revision: 25516
URL: http://www.lyx.org/trac/changeset/25516
Log:
* src/insets/InsetSpace.cpp:
- use abs().
Modified:
lyx-devel/trunk/src/insets/InsetSpace.cpp
José Matos wrote:
I am thinking particularly about bug 5010 but it can be others.
i don't think this should be a showstopper for beta4.
pavel
Pavel Sanda wrote:
José Matos wrote:
I am thinking particularly about bug 5010 but it can be others.
i don't think this should be a showstopper for beta4.
It'll be fixed, at least in large part, very soon.
rh
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Wed Jul 9 20:42:41 2008
New Revision: 25522
URL: http://www.lyx.org/trac/changeset/25522
Log:
Fix bug 5010, for the most part. There's no need to construct a default
UndoElement,
which involves constructing a default BufferParams (this is
Index: src/TextClass.cpp
===
--- src/TextClass.cpp (revision 25508)
+++ src/TextClass.cpp (working copy)
@@ -141,7 +141,7 @@
}
+Layout TextClass::createDefaultLayout(docstring const name, bool unknown) const
This
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Wed Jul 9 20:42:41 2008
New Revision: 25522
URL: http://www.lyx.org/trac/changeset/25522
Log:
Fix bug 5010, for the most part. There's no need to construct a default
UndoElement,
which involves constructing a default
So, here's the deal with 5010. As noted before, DocumentClass objects
get created via new() whenever makeDocumentClass() is called. This
happens whenever a BufferParams object is created, which was the
original problem: Such objects were getting created in the undo stuff.
Now they're not.
rgheck wrote:
So, here's the deal with 5010. As noted before, DocumentClass objects
get created via new() whenever makeDocumentClass() is called. This
happens whenever a BufferParams object is created, which was the
original problem: Such objects were getting created in the undo stuff.
Now
rgheck wrote:
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Wed Jul 9 20:42:41 2008
New Revision: 25522
URL: http://www.lyx.org/trac/changeset/25522
Log:
Fix bug 5010, for the most part. There's no need to construct a
default UndoElement,
which involves
On Wed, Jul 09, 2008 at 08:49:04PM +0200, Abdelrazak Younes wrote:
bool isFullBuffer;
+private:
+ /// Protect construction
+ UndoElement();
};
Wouldn't std::dequeUndoElement require this being pulic?
But I won't object if it just works on all supported
platforms...
Andre'
Andre Poenitz wrote:
On Wed, Jul 09, 2008 at 08:49:04PM +0200, Abdelrazak Younes wrote:
bool isFullBuffer;
+private:
+ /// Protect construction
+ UndoElement();
};
Wouldn't std::dequeUndoElement require this being pulic?
That's I thought too... weird.
Andre Poenitz wrote:
On Wed, Jul 09, 2008 at 08:49:04PM +0200, Abdelrazak Younes wrote:
bool isFullBuffer;
+private:
+ /// Protect construction
+ UndoElement();
};
Wouldn't std::dequeUndoElement require this being pulic?
But I won't object if it just works on
Andre Poenitz wrote:
On Wed, Jul 09, 2008 at 08:49:04PM +0200, Abdelrazak Younes wrote:
bool isFullBuffer;
+private:
+ /// Protect construction
+ UndoElement();
};
Wouldn't std::dequeUndoElement require this being pulic?
But I won't object if it just works on
Abdelrazak Younes wrote:
rgheck wrote:
So, here's the deal with 5010. As noted before, DocumentClass objects
get created via new() whenever makeDocumentClass() is called. This
happens whenever a BufferParams object is created, which was the
original problem: Such objects were getting
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
So, here's the deal with 5010. As noted before, DocumentClass
objects get created via new() whenever makeDocumentClass() is
called. This happens whenever a BufferParams object is created,
which was the original problem: Such objects were
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Wed Jul 9 23:27:15 2008
New Revision: 25523
URL: http://www.lyx.org/trac/changeset/25523
Log:
Fix the rest of bug 5010.
Modified:
lyx-devel/trunk/src/CutAndPaste.cpp
Modified: lyx-devel/trunk/src/CutAndPaste.cpp
URL:
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Wed Jul 9 20:42:41 2008
New Revision: 25522
URL: http://www.lyx.org/trac/changeset/25522
Log:
Fix bug 5010, for the most part. There's no need to construct a
default UndoElement,
Does this seem worth doing? It does save the construction of a
BufferParams for every undo, and Abdel seems to think it's safe
rh
Index: Undo.cpp
===
--- Undo.cpp (revision 25523)
+++ Undo.cpp (working copy)
@@ -70,11
rgheck wrote:
Does this seem worth doing? It does save the construction of a
BufferParams for every undo, and Abdel seems to think it's safe
Actually, never mind. We can't do it that way. The whole point here is
that the BufferParams could change, and we want a copy of how they were
OK, well, this may not be a huge issue, but looking closely at the Undo
code, it is noticeable that we are creating a copy of the BufferParams
for every undo operation, although---as the code says---this information
is only USED for full-document operations. So that seems like a waste of
I'm not sure whether I'm about to reiterate problems I've mentioned before
with document windows that are on someone's list to fix, or whether these
problems have been forgotten, or whether they are thought to have been fixed
but in fact are not. So with apologies if I'm just making noise ...:
On
Attached please find a polished layout patch, with restored 'browse
layout' button. Please test and comment.
The overall idea to handle unknown textclass and layouts better to
avoid data loss caused by layout conversion.
1. When a document without valid layout is loaded, a default textclass
with
Jean-Marc Lasgouttes wrote:
> Juergen, OK for branch?
Yes.
Jürgen
rgheck wrote:
> See if r25508 works for you.
It does. Thanks indeed.
Jürgen
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> This is why the paragraph should store the name of the layout, and the
>> pointer should just be a cache (that gets populated on demand, maybe).
>> There is of course a memory overhead, but this has to be evaluated.
>
> I do not know, these changes might
rgheck <[EMAIL PROTECTED]> writes:
> I think maybe you're extending the wrong thing, then. The extended
> layouts should go into the DocumentClass object associated with the
> Buffer, rather than into the LayoutFile object. I think that will
> "just work".
Very interesting indeed. Thanks.
JMarc
killermike wrote:
Abdelrazak Younes wrote:
Hi,
Question to image conversion experts:
While I agree that ImageMagick is required for more specialized
formats(*), we support already most common raster image formats
thanks to Qt, without the need for ImageMagick; for ps/pdf/eps
conversion to
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Hi,
Question to image conversion experts:
While I agree that ImageMagick is required for more specialized
formats(*), we support already most common raster image formats thanks
to Qt, without the need for
Uwe Stöhr wrote:
> While I agree that ImageMagick is required for more specialized
formats(*), we support already
> most common raster image formats thanks to Qt, without the need for
ImageMagick; for ps/pdf/eps
> conversion to png, we should just use ghostscript directly. Why you
might ask?
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> And there is nothing that really forces us to install or not IM. It is
>> just a converter among others (or it should).
>
> It is not, it is hardcoded in the code which calls 'convertDefault.py'
> which itself calls 'convert'. I am not sure LyX
[EMAIL PROTECTED] writes:
> + int length = params_.length.inBP();
> + if (length < 0)
> + length = -1 * length;
> + dim.wid = length;
What about using abs()?
JMarc
Abdelrazak Younes schrieb:
If you talk about screen effects then we already use Qt. But I didn't
know that IM was used for preparing the images before latex compilation.
Yes we use IM for that.
regards Uwe
[EMAIL PROTECTED] writes:
> Author: jamatos
> Date: Fri May 30 16:43:42 2008
> New Revision: 25012
>
> URL: http://www.lyx.org/trac/changeset/25012
> Log:
> Reduce the news of stable versions other than the first to the highlights.
Juergen, can I import this simplified version of NEWS to 1.5.x?
Hi,
I would like to change the version from 1.6.0svn to 1.6.0beta4 on
trunk.
After that I would like to see only fixes for compilation and building issues
before the versions is released and the trunk goes back to general bug fixes
again.
Is there any bug fix that you are
Jean-Marc Lasgouttes wrote:
> Juergen, can I import this simplified version of NEWS to 1.5.x? I
> think a too long NEWS file is not useful.
Yes, OK.
> If needed, I could add for
> each version an URL to the full announcement.
I don't think this is necessary.
Thanks,
Jürgen
Jean-Marc Lasgouttes wrote:
> What about using abs()?
Thanks. I knew there would be some std function %-|
Jürgen
Attached is an updated patch, not final yet.
1. When you open a document with unknown textclass, a default
textclass is added with only the standard layout.
2. All unknown layouts will be displayed as "layout (unknown)"
3. Edit and save will not lead to loss of data.
4. You can apply other
On Wed, Jul 9, 2008 at 9:03 AM, Jürgen Spitzmüller
<[EMAIL PROTECTED]> wrote:
> Nothing really crucial, but I'd like to have the attached patch at least in
> 1.6.0, since these different encodings with undescriptive names (utf8 vs.
> UTF8 vs. utf8x and EUC-JP vs. EUC-JP-pLaTEX etc.) really confuse
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Attached is an updated patch, not final yet.
>
> 1. When you open a document with unknown textclass, a default
> textclass is added with only the standard layout.
Why not "article" as we always have done?
JMarc
Jürgen Spitzmüller wrote:
> The attached patches change the behaviour. My testing didn't show any
> differences in the outtput, but I think it is to be expected that the
> output of some documents might change.
Actually, there is an unwanted change in the output due toi this patch:
Paragraphs
Bo Peng wrote:
> The more Pythonic way is if not line.startswith('Encoding')
Ah, thanks.
> SConstruct needs to be aware of the new lyx_pot call and its
> dependence on lib/encoding,
Yes, I've done that, but forgot to diff it.
> something like
>
>
>> 1. When you open a document with unknown textclass, a default
>> textclass is added with only the standard layout.
>
> Why not "article" as we always have done?
Because when I save the document, I want to keep the original layout
name so that when the right layout file comes around, I can open
"Bo Peng" <[EMAIL PROTECTED]> writes:
>>> 1. When you open a document with unknown textclass, a default
>>> textclass is added with only the standard layout.
>>
>> Why not "article" as we always have done?
>
> Because when I save the document, I want to keep the original layout
> name so that
>
> That would do the trick.
I will add it.
Other than the document-dependent unknown layouts problem (extend
DocumentClass rather than LayoutFile as Richard suggested), I am not
sure whether or not pasted text should bring unknown layouts to a
document. These layouts will not cause any trouble
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Other than the document-dependent unknown layouts problem (extend
> DocumentClass rather than LayoutFile as Richard suggested), I am not
> sure whether or not pasted text should bring unknown layouts to a
> document.
I think they should. This simplifies
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Juergen, can I import this simplified version of NEWS to 1.5.x? I
>> think a too long NEWS file is not useful.
>
> Yes, OK.
Done.
JMarc
Jean-Marc Lasgouttes wrote:
> > Yes, OK.
>
> Done.
Thank you.
Jürgen
On Wed, Jul 09, 2008 at 10:31:17AM -, [EMAIL PROTECTED] wrote:
> Author: spitz
> Date: Wed Jul 9 12:31:16 2008
> New Revision: 25516
>
> URL: http://www.lyx.org/trac/changeset/25516
> Log:
> * src/insets/InsetSpace.cpp:
> - use abs().
>
> Modified:
>
José Matos wrote:
> I am thinking particularly about bug 5010 but it can be others.
i don't think this should be a showstopper for beta4.
pavel
Pavel Sanda wrote:
José Matos wrote:
I am thinking particularly about bug 5010 but it can be others.
i don't think this should be a showstopper for beta4.
It'll be fixed, at least in large part, very soon.
rh
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Wed Jul 9 20:42:41 2008
New Revision: 25522
URL: http://www.lyx.org/trac/changeset/25522
Log:
Fix bug 5010, for the most part. There's no need to construct a default
UndoElement,
which involves constructing a default BufferParams (this is
Index: src/TextClass.cpp
===
--- src/TextClass.cpp (revision 25508)
+++ src/TextClass.cpp (working copy)
@@ -141,7 +141,7 @@
}
+Layout TextClass::createDefaultLayout(docstring const & name, bool unknown) const
This
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Wed Jul 9 20:42:41 2008
New Revision: 25522
URL: http://www.lyx.org/trac/changeset/25522
Log:
Fix bug 5010, for the most part. There's no need to construct a default
UndoElement,
which involves constructing a default
So, here's the deal with 5010. As noted before, DocumentClass objects
get created via new() whenever makeDocumentClass() is called. This
happens whenever a BufferParams object is created, which was the
original problem: Such objects were getting created in the undo stuff.
Now they're not.
rgheck wrote:
So, here's the deal with 5010. As noted before, DocumentClass objects
get created via new() whenever makeDocumentClass() is called. This
happens whenever a BufferParams object is created, which was the
original problem: Such objects were getting created in the undo stuff.
Now
rgheck wrote:
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Wed Jul 9 20:42:41 2008
New Revision: 25522
URL: http://www.lyx.org/trac/changeset/25522
Log:
Fix bug 5010, for the most part. There's no need to construct a
default UndoElement,
which involves
On Wed, Jul 09, 2008 at 08:49:04PM +0200, Abdelrazak Younes wrote:
> > bool isFullBuffer;
> > +private:
> > + /// Protect construction
> > + UndoElement();
> > };
Wouldn't std::deque require this being pulic?
But I won't object if it "just works" on all supported
platforms...
Andre'
Andre Poenitz wrote:
On Wed, Jul 09, 2008 at 08:49:04PM +0200, Abdelrazak Younes wrote:
bool isFullBuffer;
+private:
+ /// Protect construction
+ UndoElement();
};
Wouldn't std::deque require this being pulic?
That's I thought too... weird.
But I won't
Andre Poenitz wrote:
On Wed, Jul 09, 2008 at 08:49:04PM +0200, Abdelrazak Younes wrote:
bool isFullBuffer;
+private:
+ /// Protect construction
+ UndoElement();
};
Wouldn't std::deque require this being pulic?
But I won't object if it "just works" on all
Andre Poenitz wrote:
On Wed, Jul 09, 2008 at 08:49:04PM +0200, Abdelrazak Younes wrote:
bool isFullBuffer;
+private:
+ /// Protect construction
+ UndoElement();
};
Wouldn't std::deque require this being pulic?
But I won't object if it "just works" on all
Abdelrazak Younes wrote:
rgheck wrote:
So, here's the deal with 5010. As noted before, DocumentClass objects
get created via new() whenever makeDocumentClass() is called. This
happens whenever a BufferParams object is created, which was the
original problem: Such objects were getting
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
So, here's the deal with 5010. As noted before, DocumentClass
objects get created via new() whenever makeDocumentClass() is
called. This happens whenever a BufferParams object is created,
which was the original problem: Such objects were
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Wed Jul 9 23:27:15 2008
New Revision: 25523
URL: http://www.lyx.org/trac/changeset/25523
Log:
Fix the rest of bug 5010.
Modified:
lyx-devel/trunk/src/CutAndPaste.cpp
Modified: lyx-devel/trunk/src/CutAndPaste.cpp
URL:
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Wed Jul 9 20:42:41 2008
New Revision: 25522
URL: http://www.lyx.org/trac/changeset/25522
Log:
Fix bug 5010, for the most part. There's no need to construct a
default UndoElement,
Does this seem worth doing? It does save the construction of a
BufferParams for every undo, and Abdel seems to think it's safe
rh
Index: Undo.cpp
===
--- Undo.cpp (revision 25523)
+++ Undo.cpp (working copy)
@@ -70,11
rgheck wrote:
Does this seem worth doing? It does save the construction of a
BufferParams for every undo, and Abdel seems to think it's safe
Actually, never mind. We can't do it that way. The whole point here is
that the BufferParams could change, and we want a copy of how they were
OK, well, this may not be a huge issue, but looking closely at the Undo
code, it is noticeable that we are creating a copy of the BufferParams
for every undo operation, although---as the code says---this information
is only USED for full-document operations. So that seems like a waste of
I'm not sure whether I'm about to reiterate problems I've mentioned before
with document windows that are on someone's list to fix, or whether these
problems have been forgotten, or whether they are thought to have been fixed
but in fact are not. So with apologies if I'm just making noise ...:
On
Attached please find a polished layout patch, with restored 'browse
layout' button. Please test and comment.
The overall idea to handle unknown textclass and layouts better to
avoid data loss caused by layout conversion.
1. When a document without valid layout is loaded, a default textclass
with
94 matches
Mail list logo
