Abdelrazak Younes wrote:
> OK but note that I think this mean that a single math inset in a
> paragraph, no matter where will trigger a full redraw in any case.
I know. That's certainly not ideal, but we're going to get back to the issue
for 1.5.3 (and 1.5.2 still has enough improvements).
Jürge
Juergen Spitzmueller wrote:
Abdelrazak Younes wrote:
OK then revert the optimization as I don't want to spend too much time
on it.
done.
OK but note that I think this mean that a single math inset in a
paragraph, no matter where will trigger a full redraw in any case.
Abdel.
Abdelrazak Younes wrote:
> OK then revert the optimization as I don't want to spend too much time
> on it.
done.
Jürgen
Juergen Spitzmueller wrote:
Abdelrazak Younes wrote:
Could you please try this?
Doesn't work, unfortunately.
OK then revert the optimization as I don't want to spend too much time
on it.
Abdel.
Abdelrazak Younes wrote:
> Could you please try this?
Doesn't work, unfortunately.
Jürgen
Juergen Spitzmueller wrote:
Abdelrazak Younes wrote:
Too bad, this optimization is quite necessary. I think that this should
be resolved by forcing a full repaint when editing within a table.
But if we don't have a quick and straightforward fix,
Could you please try this?
Abdel.
Index: Ins
Abdelrazak Younes wrote:
> Are you sure you don't want my wide() removal patch? As 1.5.2 has been
> delayed, I reckon there is enough time to test it.
I want to prepare the tarball tomorrow and release on monday. 1.5.2 is
overdue. I think the wide change would require some more time.
Jürgen
Juergen Spitzmueller wrote:
Abdelrazak Younes wrote:
Too bad, this optimization is quite necessary. I think that this should
be resolved by forcing a full repaint when editing within a table.
But if we don't have a quick and straightforward fix, we will have to revert
for the time being
Are
Abdelrazak Younes wrote:
> Too bad, this optimization is quite necessary. I think that this should
> be resolved by forcing a full repaint when editing within a table.
But if we don't have a quick and straightforward fix, we will have to revert
for the time being (and are you sure there are no ot
Juergen Spitzmueller wrote:
I wonder if this is the culprit:
http://www.lyx.org/trac/changeset/20567
And it is. I just reverted this and verified.
Too bad, this optimization is quite necessary. I think that this should
be resolved by forcing a full repaint when editing within a table.
Abde
> I wonder if this is the culprit:
> http://www.lyx.org/trac/changeset/20567
And it is. I just reverted this and verified.
Jürgen
Abdelrazak Younes wrote:
> That's the patch bringing fixed width float (bug 4002) that is the
> problem not the box fix. If I can't come up with a patch soon it'd be
> easy to revert this commit before 1.5.2. Sorry, I've tested this only
> with figure floats.
I wonder if this is the culprit:
http
Abdelrazak Younes wrote:
> Could someone please try to comment out line 52 of InsetFloat.h and see
> if that fixes the problem?
>
> bool hasFixedWidth() const { return true; }
No. It would have surprised me if it did, actually, since float shouldn't
have any impact on a tabular redraw, should it
Abdelrazak Younes wrote:
Juergen Spitzmueller wrote:
Michael Gerz wrote:
if you edit a table with 1.5.2svn such that the width of the table
shrinks, you see some ugly artefacts on the right of the table.
I see this, too. Looks like an update issue.
Oh... I see this too within a float (I wa
Juergen Spitzmueller wrote:
Abdelrazak Younes wrote:
Could you give a more precise recipe to reproduce this please?
It's easy. Just insert a table, type some text in a cell, and press
backspace to delete the text again. Clicking in the workarea fixes the
display.
OK then it's not that probl
Abdelrazak Younes wrote:
> Could you give a more precise recipe to reproduce this please?
It's easy. Just insert a table, type some text in a cell, and press
backspace to delete the text again. Clicking in the workarea fixes the
display.
We used to have the same problem in listings (but it's sol
Juergen Spitzmueller wrote:
Michael Gerz wrote:
if you edit a table with 1.5.2svn such that the width of the table
shrinks, you see some ugly artefacts on the right of the table.
I see this, too. Looks like an update issue.
Oh... I see this too within a float (I was just
This problem doe
Juergen Spitzmueller wrote:
Michael Gerz wrote:
if you edit a table with 1.5.2svn such that the width of the table
shrinks, you see some ugly artefacts on the right of the table.
I see this, too. Looks like an update issue.
Could you give a more precise recipe to reproduce this please?
Michael Gerz wrote:
> if you edit a table with 1.5.2svn such that the width of the table
> shrinks, you see some ugly artefacts on the right of the table.
I see this, too. Looks like an update issue.
> This problem does not appear with 1.5.1 and has been introduced within
> the last 2 or 3 weeks
> if you edit a table with 1.5.2svn such that the width of the table shrinks,
> you see some ugly artefacts on the right of the table.
this has been also the case with the Box before the fixed-width patch arrived.
maybe it has something common.
pavel
Hi,
if you edit a table with 1.5.2svn such that the width of the table
shrinks, you see some ugly artefacts on the right of the table.
This problem does not appear with 1.5.1 and has been introduced within
the last 2 or 3 weeks.
Michael
21 matches
Mail list logo
