Re: [LyX/master] Aesthetics: off-by-one in line drawing
On 07/23/2018 11:19 AM, Jean-Marc Lasgouttes wrote: > Le 23/07/2018 à 17:19, Jean-Marc Lasgouttes a écrit : >> commit ad954a32a525828bd03bf2c8241252e60394cbc3 >> Author: Jean-Marc Lasgouttes >> Date: Mon Jul 23 17:07:48 2018 +0200 >> >> Aesthetics: off-by-one in line drawing >> It is a general problem when doing graphics to know where a >> line >> begins and where it ends pixel-wise. At the instigation of >> Scott, and >> with the use of the kmag magnifier, this commit corrects 3 areas: >> * foreign marks were larger than the row element they were >> supposed to >> mark. This could lead to moving lines, depending on paint >> ordering. >> * visible spaces were drawn outside of their box (select a >> single >> space to see this). >> * the `L' blinking caret would leave a cursor dropping >> because the >> horizontal part was too wide. > > I am sure thee are other off-by-one errors like that, keep them coming > > Riki, assuming that Scott's eyes hurt less now, this is candidate for > branch. Your choice, 2.3.1 or 2.3.2. Riki
Re: [LyX/master] Improve DEPM
On 07/23/2018 03:04 AM, Jean-Marc Lasgouttes wrote: > Le 23/07/2018 à 04:15, Richard Kimberly Heck a écrit : >> It sounds good in principle. >> >> Is this a possibility for 2.3.x? If so, you can commit to stable once >> 2.3.1 is out. Then it should get lots of testing. > > I had tentatively set set milestone 2.3.2 for ticket #10503. OK. Riki
Re: [LyX/master] Aesthetics: off-by-one in line drawing
On Mon, Jul 23, 2018 at 03:19:51PM +, Jean-Marc Lasgouttes wrote: > Le 23/07/2018 à 17:19, Jean-Marc Lasgouttes a écrit : > > commit ad954a32a525828bd03bf2c8241252e60394cbc3 > > Author: Jean-Marc Lasgouttes > > Date: Mon Jul 23 17:07:48 2018 +0200 > > > > Aesthetics: off-by-one in line drawing > > It is a general problem when doing graphics to know where a line > > begins and where it ends pixel-wise. At the instigation of Scott, and > > with the use of the kmag magnifier, this commit corrects 3 areas: > > * foreign marks were larger than the row element they were supposed to > >mark. This could lead to moving lines, depending on paint ordering. > > * visible spaces were drawn outside of their box (select a single > >space to see this). > > * the `L' blinking caret would leave a cursor dropping because the > >horizontal part was too wide. > > I am sure thee are other off-by-one errors like that, keep them coming Thanks, just tested briefly and works well! > Riki, assuming that Scott's eyes hurt less now, this is candidate for > branch. It would bother me if I came across it in my work-related documents, but I only came across the issue when looking into something else, so there's no rush on my behalf. Scott signature.asc Description: PGP signature
Re: [LyX/master] Draw top/bottom rules heavier for booktab
On Mon, Jul 23, 2018 at 4:14 PM, Jean-Marc Lasgouttes wrote: > Le 23/07/2018 à 22:46, Daniel a écrit : > >> On 23/07/2018 20:40, Jean-Marc Lasgouttes wrote: >> >>> Le 23/07/2018 à 20:26, Daniel a écrit : >>> With 3 pixels for heavy, I will have to take the width into account in > table cells height computation, while I have conveniently decided to > ignore > it for now :) > Why is it that you would have to take it into account? So far zooming keeps the cell padding (emprty space around cell content) fixes. So nothing would overlap or so. >>> >>> I do not know, I have not tried it. But I suspect thatit would seem too >>> bold. I may try to do it if I find the time. >>> >> >> I think it will look good. >> > > OK I see you point. You will not stop until I comply. > > I did it now and don't like much. It is in though for your enjoyment. > I also prefer the prior "new" treatment versus this newest styling. > If something is not yet correct, I propose to revert the whole thing and > go back to the time when nobody complained ;) > I hope this doesn't occur but rather the initial salvo of changes are kept. - Joel
Re: [LyX/master] Draw top/bottom rules heavier for booktab
Le 23/07/2018 à 22:46, Daniel a écrit : On 23/07/2018 20:40, Jean-Marc Lasgouttes wrote: Le 23/07/2018 à 20:26, Daniel a écrit : With 3 pixels for heavy, I will have to take the width into account in table cells height computation, while I have conveniently decided to ignore it for now :) Why is it that you would have to take it into account? So far zooming keeps the cell padding (emprty space around cell content) fixes. So nothing would overlap or so. I do not know, I have not tried it. But I suspect thatit would seem too bold. I may try to do it if I find the time. I think it will look good. OK I see you point. You will not stop until I comply. I did it now and don't like much. It is in though for your enjoyment. If something is not yet correct, I propose to revert the whole thing and go back to the time when nobody complained ;) JMarc
Re: [LyX/master] Draw top/bottom rules heavier for booktab
On 23/07/2018 20:40, Jean-Marc Lasgouttes wrote: Le 23/07/2018 à 20:26, Daniel a écrit : With 3 pixels for heavy, I will have to take the width into account in table cells height computation, while I have conveniently decided to ignore it for now :) Why is it that you would have to take it into account? So far zooming keeps the cell padding (emprty space around cell content) fixes. So nothing would overlap or so. I do not know, I have not tried it. But I suspect thatit would seem too bold. I may try to do it if I find the time. I think it will look good. Daniel
Re: [LyX/master] Draw top/bottom rules heavier for booktab
Le 23/07/2018 à 20:26, Daniel a écrit : With 3 pixels for heavy, I will have to take the width into account in table cells height computation, while I have conveniently decided to ignore it for now :) Why is it that you would have to take it into account? So far zooming keeps the cell padding (emprty space around cell content) fixes. So nothing would overlap or so. I do not know, I have not tried it. But I suspect thatit would seem too bold. I may try to do it if I find the time. Yes, barely visible does not sound good. Strange that there is no in between 1 and 2 for HiDPI displays. Well, would only solve the "problem" for those diaplys anyway. It is possible, as long as we use doubles (aka real numbers) instead of integers all over out painting system. That would require a fair amount of changes. JMarc
Re: [LyX/master] Draw top/bottom rules heavier for booktab
On 23/07/2018 15:09, Jean-Marc Lasgouttes wrote: Le 23/07/2018 à 10:16, Daniel a écrit : Okay, got it. And using 3 pixel for heavy, 1 pixel for thin, and 2 pixel for medium doesn't look good? A reason to even trade-off some of the good looks is that having only partly a distinction between different lines might be misleading. With 3 pixels for heavy, I will have to take the width into account in table cells height computation, while I have conveniently decided to ignore it for now :) Why is it that you would have to take it into account? So far zooming keeps the cell padding (emprty space around cell content) fixes. So nothing would overlap or so. Note that the distinction between \midrule and \cmidrule is kind if obvious since one of them does not cover all columns. We ar esomewher ein the middle between WYSYWYG and WYSYWIM here. I just want to convey what a booktab look like. Me too. But it would be nice to have a visual cue when a rule width changes. It's not so obvious, I think. I could set the width of cmidrule to 0, with would be the same as 1 for normal screens and a barely visible one-real-pixel wide line on Mac Retina. Yes, barely visible does not sound good. Strange that there is no in between 1 and 2 for HiDPI displays. Well, would only solve the "problem" for those diaplys anyway. Daniel
Re: [LyX/master] Aesthetics: off-by-one in line drawing
Le 23/07/2018 à 17:19, Jean-Marc Lasgouttes a écrit :
commit ad954a32a525828bd03bf2c8241252e60394cbc3
Author: Jean-Marc Lasgouttes
Date: Mon Jul 23 17:07:48 2018 +0200
Aesthetics: off-by-one in line drawing
It is a general problem when doing graphics to know where a line
begins and where it ends pixel-wise. At the instigation of Scott, and
with the use of the kmag magnifier, this commit corrects 3 areas:
* foreign marks were larger than the row element they were supposed to
mark. This could lead to moving lines, depending on paint ordering.
* visible spaces were drawn outside of their box (select a single
space to see this).
* the `L' blinking caret would leave a cursor dropping because the
horizontal part was too wide.
I am sure thee are other off-by-one errors like that, keep them coming
Riki, assuming that Scott's eyes hurt less now, this is candidate for
branch.
JMarc
---
src/RowPainter.cpp|2 +-
src/frontends/qt4/GuiWorkArea.cpp |4 ++--
src/insets/InsetSpace.cpp | 12 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/RowPainter.cpp b/src/RowPainter.cpp
index 16b144e..efc4021 100644
--- a/src/RowPainter.cpp
+++ b/src/RowPainter.cpp
@@ -159,7 +159,7 @@ void RowPainter::paintForeignMark(Row::Element const & e)
const
int const desc = e.inset ? e.dim.descent() : 0;
int const y = yo_ + min(3 * pi_.base.solidLineOffset() / 2 + desc,
row_.descent() - 1);
- pi_.pain.line(int(x_), y, int(x_ + e.full_width()), y, Color_language,
+ pi_.pain.line(int(x_), y, int(x_ + e.full_width() - 1), y,
Color_language,
Painter::line_solid, pi_.base.solidLineThickness());
}
diff --git a/src/frontends/qt4/GuiWorkArea.cpp b/src/frontends/qt4/GuiWorkArea.cpp
index e6d993c..45c4469 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -150,9 +150,9 @@ public:
painter.setPen(color_);
if (l_shape_) {
if (rtl_)
- painter.drawLine(x_, bot, x_ - l, bot);
+ painter.drawLine(x_, bot, x_ - l + 1, bot);
else
- painter.drawLine(x_, bot, x_ + caret_width_ +
r, bot);
+ painter.drawLine(x_, bot, x_ + caret_width_ + r
- 1, bot);
}
// draw completion triangle
diff --git a/src/insets/InsetSpace.cpp b/src/insets/InsetSpace.cpp
index fd8c261..ddb85b7 100644
--- a/src/insets/InsetSpace.cpp
+++ b/src/insets/InsetSpace.cpp
@@ -355,18 +355,18 @@ void InsetSpace::draw(PainterInfo & pi, int x, int y)
const
int const h = theFontMetrics(pi.base.font).xHeight();
int xp[4], yp[4];
- xp[0] = x;
+ xp[0] = x + 1;
yp[0] = y - max(h / 4, 1);
if (params_.kind == InsetSpaceParams::NORMAL ||
params_.kind == InsetSpaceParams::PROTECTED ||
params_.kind == InsetSpaceParams::VISIBLE) {
- xp[1] = x; yp[1] = y;
- xp[2] = x + w; yp[2] = y;
+ xp[1] = x + 1; yp[1] = y;
+ xp[2] = x + w - 2; yp[2] = y;
} else {
- xp[1] = x; yp[1] = y + max(h / 4, 1);
- xp[2] = x + w; yp[2] = y + max(h / 4, 1);
+ xp[1] = x + 1; yp[1] = y + max(h / 4, 1);
+ xp[2] = x + w - 2; yp[2] = y + max(h / 4, 1);
}
- xp[3] = x + w;
+ xp[3] = x + w - 2;
yp[3] = y - max(h / 4, 1);
Color col = Color_special;
Re: [LyX/master] Do the actual drawing in the paint event
Le 20/07/2018 à 13:50, Scott Kostyshak a écrit : With high zoom levels, I noticed a separate issue. It is much more minor, but in case it is related I will describe it. The blue lines change length based on cursor movement. It is very subtle, but if you flip between the attached screenshots, you will see the blue lines changing length based on the cursor position. In case it is difficult to see, I attach difference.png. Zoom in and look at the red dots on the ends of a couple of the blue lines. I can reproduce this problem. As I see it, the blue line of text goes over the blue line of insets (this happens around insets). Therefore, when only insets are painted, the erase the extra pixels. JMarc
Re: [LyX/master] Draw top/bottom rules heavier for booktab
Le 23/07/2018 à 15:19, Joel Kulesza a écrit : On Mon, Jul 23, 2018 at 7:09 AM, Jean-Marc Lasgouttes mailto:lasgout...@lyx.org>> wrote: I could set the width of cmidrule to 0, with would be the same as 1 for normal screens and a **barely visible one-real-pixel wide line on Mac Retina**. Please don't do this. I hoped someone would say that ;) JMarc
Re: Failing exports
2018-07-22 7:44 GMT+02:00 Kornel Benko :
> Am Samstag, 21. Juli 2018 20:03:14 CEST schrieb Jürgen Spitzmüller <
> sp...@lyx.org>:
> > Am Samstag, den 21.07.2018, 19:34 +0200 schrieb Kornel Benko:
> > > examples/europeCV, examples/es/europeCV
> > > Runaway argument?
> > > ! Paragraph ended before \\ecvtelephone was complete.
> > >
> > >\par
> > > l.39
> > >
> > > I suspect you've forgotten a `}', causing me to apply this
> > > control sequence to too much text. How can we recover?
> > > My plan is to forget the whole thing and hope for the best.
> >
> > \ecvtelephone got a second mandatory argument in the recent release:
> >
> > \ecvtelephone[mobile]{home}{office}
> >
> > We need to support this in the layout. But it's not really backwards
> > compatible.
>
The europecv issues have been fixed upstream and will be part of the next
release of the class (which should be due soon).
We still should add support for the new features eventually, but at least
our documents will compile again after the update.
Jürgen
Re: [LyX/master] Draw top/bottom rules heavier for booktab
On Mon, Jul 23, 2018 at 7:09 AM, Jean-Marc Lasgouttes wrote: > I could set the width of cmidrule to 0, with would be the same as 1 for > normal screens and a **barely visible one-real-pixel wide line on Mac > Retina**. Please don't do this.
Re: [LyX/master] Draw top/bottom rules heavier for booktab
Le 23/07/2018 à 10:16, Daniel a écrit : Okay, got it. And using 3 pixel for heavy, 1 pixel for thin, and 2 pixel for medium doesn't look good? A reason to even trade-off some of the good looks is that having only partly a distinction between different lines might be misleading. With 3 pixels for heavy, I will have to take the width into account in table cells height computation, while I have conveniently decided to ignore it for now :) Note that the distinction between \midrule and \cmidrule is kind if obvious since one of them does not cover all columns. We ar esomewher ein the middle between WYSYWYG and WYSYWIM here. I just want to convey what a booktab look like. I could set the width of cmidrule to 0, with would be the same as 1 for normal screens and a barely visible one-real-pixel wide line on Mac Retina. JMarc
Re: [LyX/master] Draw top/bottom rules heavier for booktab
On 22/07/2018 20:29, Jean-Marc Lasgouttes wrote: Le 22/07/2018 à 18:59, Daniel a écrit : But I am a bit lost. You state the widths above as em fractions but say that the values are integers. Do you mean that the list of widths widths above are as defined in the booktab package but you are using integer values to set the line width in LyX? The em values are indeed what booktabs defines. However, they all correspond to <1 pixel values except when dpi is very high. So I have hardcoded to 2 pixels for heavy and 1 pixel for thin. A reason for not taking dpi into account is that no everybody agree that lines should become thicker with zoom. Okay, got it. And using 3 pixel for heavy, 1 pixel for thin, and 2 pixel for medium doesn't look good? A reason to even trade-off some of the good looks is that having only partly a distinction between different lines might be misleading. Daniel
Re: Russian Translation Update
Am Freitag, den 20.07.2018, 20:32 +0300 schrieb Юрий Скалько: > And another update with more corrections for LyX 2.3.x branch. Thanks, Yuriy. I committed to 2.3.x. Jürgen PS. Riki, are you subscribed to po-updates? > > 2018-07-20 13:44 GMT+03:00 Юрий Скалько : > > Hello. > > > > I've updated Russian translation for LyX 2.3. Please check the > > attached ZIP. > > > > Regards, > > Yuriy signature.asc Description: This is a digitally signed message part
Re: [LyX/master] Improve DEPM
Le 23/07/2018 à 04:15, Richard Kimberly Heck a écrit : It sounds good in principle. Is this a possibility for 2.3.x? If so, you can commit to stable once 2.3.1 is out. Then it should get lots of testing. I had tentatively set set milestone 2.3.2 for ticket #10503. JMarc
