Re: integral upper limit adjacent to integral sign

2018-03-19 Thread Scott Kostyshak
On Mon, Mar 19, 2018 at 11:06:43AM +, Jean-Marc Lasgouttes wrote:
> Le 17/02/2018 à 17:00, Jean-Marc Lasgouttes a écrit :
> > Le 07/02/2018 à 11:56, Enrico Forestieri a écrit :
> > > On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote:
> > > > I tried a vanilla "git revert" on master and there was a conflict so I
> > > > did not look further. If you have a patch that reverts it, I could test
> > > > that.
> > > 
> > > Please, try the attached.
> > 
> > Here is a version of this revert that still takes care of the \not case.
> > It _seems_ to work and I pushed it to master for evaluation.
> 
> What about 2.3?

No strong opinion.

> Is everyone happy with superscripts now? I know it is not
> perfect, but I am not sure I can improve on it.

You mean in master, right? I think it's OK now. Hopefully we can
eventually offset the subscript and superscript as we used to do, which
corresponds with the PDF output.

Scott


signature.asc
Description: PGP signature


Re: integral upper limit adjacent to integral sign

2018-03-19 Thread Jean-Marc Lasgouttes

Le 17/02/2018 à 17:00, Jean-Marc Lasgouttes a écrit :

Le 07/02/2018 à 11:56, Enrico Forestieri a écrit :

On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote:

I tried a vanilla "git revert" on master and there was a conflict so I
did not look further. If you have a patch that reverts it, I could test
that.


Please, try the attached.


Here is a version of this revert that still takes care of the \not case. 
It _seems_ to work and I pushed it to master for evaluation.


What about 2.3? Is everyone happy with superscripts now? I know it is 
not perfect, but I am not sure I can improve on it.


JMarc


Re: integral upper limit adjacent to integral sign

2018-02-23 Thread Jean-Marc Lasgouttes

Le 15/02/2018 à 16:54, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

Le 15 février 2018 16:32:23 GMT+01:00, Jean-Marc Lasgouttes 
 a écrit :


I can try to prepare that. What character you want me to paste there?
I can't take 'f' from esint, there is no 'f' included. Pavel


The integral at position 1.


And glyph number 4, I think.


Try this one:
195.113.26.193/~sanda/junk/DejaVuSerif-Italic.ttf
At f position you have esint glyph 1, at 'g' position you have glyph 4.
Pavel


I tried to see what to do with it, but this is beyond the time I am 
ready to spend on this issue :) The learning curve is a bit too steep 
for the reward.


JMarc



Re: integral upper limit adjacent to integral sign

2018-02-17 Thread Jean-Marc Lasgouttes

Le 07/02/2018 à 11:56, Enrico Forestieri a écrit :

On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote:

I tried a vanilla "git revert" on master and there was a conflict so I
did not look further. If you have a patch that reverts it, I could test
that.


Please, try the attached.


Here is a version of this revert that still takes care of the \not case. 
It _seems_ to work and I pushed it to master for evaluation.


JMarc

>From 5861df71721ddf823e5b01e0d9b8f4b97da58a97 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Sat, 17 Feb 2018 16:55:22 +0100
Subject: [PATCH] Another go at fixing string metrics

This time, it is the problems with \int in esint and cmex that we are
trying to work around. This code is becoming too complicated to my
taste.
---
 src/frontends/qt4/GuiFontMetrics.cpp | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp
index b9eab8531f..c2d4b884e4 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -181,26 +181,38 @@ int GuiFontMetrics::width(docstring const & s) const
 	if (strwidth_cache_.contains(s))
 		return strwidth_cache_[s];
 	PROFILE_CACHE_MISS(width);
-	/* For some reason QMetrics::width returns a wrong value with Qt5
-	 * with some arabic text. OTOH, QTextLayout is broken for single
-	 * characters with null width (like \not in mathed). Also, as a
-	 * safety measure, always use QMetrics::width with our math fonts.
+	/* Several problems have to be taken into account:
+	 * * QFontMetrics::width does not returns a wrong value with Qt5 with
+	 *   some arabic text, since the glyph-shaping operations are not
+	 *   done (documented in Qt5).
+	 * * QTextLayout is broken for single characters with null width
+	 *   (like \not in mathed).
+	 * * While QTextLine::horizontalAdvance is the right thing to use
+ *   for text strings, it does not give a good result with some
+ *   characters like the \int (gyph 4) of esint.
+
+	 * Also, as a safety measure, always use QFontMetrics::width with
+	 * our math fonts.
 	*/
 	int w = 0;
-	if (s.length() == 1
+	// is the string a single character from a math font ?
 #if QT_VERSION >= 0x040800
-	|| font_.styleName() == "LyX"
+	bool const math_char = s.length() == 1 || font_.styleName() == "LyX";
+#else
+	bool const math_char = s.length() == 1;
 #endif
-	)
-		w = metrics_.width(toqstr(s));
-	else {
+	// keep value 0 for math chars with width 0
+	if (!math_char || metrics_.width(toqstr(s)) != 0) {
 		QTextLayout tl;
 		tl.setText(toqstr(s));
 		tl.setFont(font_);
 		tl.beginLayout();
 		QTextLine line = tl.createLine();
 		tl.endLayout();
-		w = iround(line.horizontalAdvance());
+		if (math_char)
+			w = iround(line.naturalTextWidth());
+		else
+			w = iround(line.horizontalAdvance());
 	}
 	strwidth_cache_.insert(s, w, s.size() * sizeof(char_type));
 	return w;
-- 
2.14.1



Re: integral upper limit adjacent to integral sign

2018-02-15 Thread Pavel Sanda
Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
> > Le 15 février 2018 16:32:23 GMT+01:00, Jean-Marc Lasgouttes 
> >  a écrit :
> > 
> > >>I can try to prepare that. What character you want me to paste there?
> > >>I can't take 'f' from esint, there is no 'f' included. Pavel
> > >
> > >The integral at position 1.
> > 
> > And glyph number 4, I think.
> 
> Try this one:
> 195.113.26.193/~sanda/junk/DejaVuSerif-Italic.ttf
> At f position you have esint glyph 1, at 'g' position you have glyph 4.

One difference I could immediatelly spot was that dejavu italic has
set 'angle' -11 degrees, because it's italic font, while we have 0
for esint if it matters for your debug...

Pavel


Re: integral upper limit adjacent to integral sign

2018-02-15 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> Le 15 février 2018 16:32:23 GMT+01:00, Jean-Marc Lasgouttes 
>  a écrit :
> 
> >>I can try to prepare that. What character you want me to paste there?
> >>I can't take 'f' from esint, there is no 'f' included. Pavel
> >
> >The integral at position 1.
> 
> And glyph number 4, I think.

Try this one:
195.113.26.193/~sanda/junk/DejaVuSerif-Italic.ttf
At f position you have esint glyph 1, at 'g' position you have glyph 4.
Pavel


Re: integral upper limit adjacent to integral sign

2018-02-15 Thread Jean-Marc Lasgouttes
Le 15 février 2018 16:32:23 GMT+01:00, Jean-Marc Lasgouttes 
 a écrit :

>>I can try to prepare that. What character you want me to paste there?
>>I can't take 'f' from esint, there is no 'f' included. Pavel
>
>The integral at position 1.

And glyph number 4, I think.

JMarc



Re: integral upper limit adjacent to integral sign

2018-02-15 Thread Jean-Marc Lasgouttes
Le 15 février 2018 16:23:16 GMT+01:00, Pavel Sanda  a écrit :
>Jean-Marc Lasgouttes wrote:
>> Le 15/02/2018 ?? 16:13, Pavel Sanda a écrit :
>>> So what about copy-paste esint(f) into DejaVuSerif-Italic via
>fontforge
>>> and check what happens.
>>> If there is some metainfo set wrong we could use Dejavu as a
>skeleton
>>> and copy our symbols there...
>>
>> I never used fontforge to modify a font...
>
>I can try to prepare that. What character you want me to paste there?
>I can't take 'f' from esint, there is no 'f' included. Pavel

The integral at position 1.

JMarc

Re: integral upper limit adjacent to integral sign

2018-02-15 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> Le 15/02/2018 ?? 16:13, Pavel Sanda a écrit :
>> So what about copy-paste esint(f) into DejaVuSerif-Italic via fontforge
>> and check what happens.
>> If there is some metainfo set wrong we could use Dejavu as a skeleton
>> and copy our symbols there...
>
> I never used fontforge to modify a font...

I can try to prepare that. What character you want me to paste there?
I can't take 'f' from esint, there is no 'f' included. Pavel


Re: integral upper limit adjacent to integral sign

2018-02-15 Thread Jean-Marc Lasgouttes

Le 15/02/2018 à 16:13, Pavel Sanda a écrit :

So what about copy-paste esint(f) into DejaVuSerif-Italic via fontforge
and check what happens.
If there is some metainfo set wrong we could use Dejavu as a skeleton
and copy our symbols there...


I never used fontforge to modify a font...

JMarc


Re: integral upper limit adjacent to integral sign

2018-02-15 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> Le 14/02/2018 ?? 17:11, Pavel Sanda a écrit :
>> Jean-Marc Lasgouttes wrote:
>>> I took a look at the Qt4 and Qt5 code and did not see a difference. It
>>> might be that our fonts are malformed.
>> I loaded esint10.ttf into fontforge and when I go to Metrics->set 
>> L/RBearings
>> of integral sign (#1) I see the value 113.5.
>> I doesn't look as what your log stated or do I read it wrong?
>
> You read it right, ttfdump says the same in the glyf/hmtx  tables.
>
> My problem if the DejaVuSerif-Italic, where I take my italic f, has similar 
> values, but Qt return good results. I suspect that there are other values 
> somewhere in the font that conflict with our metrics.

So what about copy-paste esint(f) into DejaVuSerif-Italic via fontforge
and check what happens.
If there is some metainfo set wrong we could use Dejavu as a skeleton
and copy our symbols there...

Pavel


Re: integral upper limit adjacent to integral sign

2018-02-15 Thread Jean-Marc Lasgouttes

Le 14/02/2018 à 17:11, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

I took a look at the Qt4 and Qt5 code and did not see a difference. It
might be that our fonts are malformed.


I loaded esint10.ttf into fontforge and when I go to Metrics->set L/RBearings
of integral sign (#1) I see the value 113.5.
I doesn't look as what your log stated or do I read it wrong?


You read it right, ttfdump says the same in the glyf/hmtx  tables.

My problem if the DejaVuSerif-Italic, where I take my italic f, has 
similar values, but Qt return good results. I suspect that there are 
other values somewhere in the font that conflict with our metrics.


JMarc


Re: integral upper limit adjacent to integral sign

2018-02-15 Thread Jean-Marc Lasgouttes

Le 14/02/2018 à 16:50, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

I have tried to run ttfdump on the ttf files, and it shows properly
negative right bearings for both fonts. At this point, I give up :)


Maybe we can try bipartisan attempt on Qt bug tracking system.
I recently filled up the bug for Qt5 not rendering characters
for certain codepoints, maybe we get more attention if we report
this as a part of the bug(?).

https://bugreports.qt.io/browse/QTBUG-66266


I think it should be a different bug. But I am not sure yet whether it 
is a bug in

- our fonts
- freetype
- Qt itself.

JMarc



Re: integral upper limit adjacent to integral sign

2018-02-14 Thread Scott Kostyshak
On Wed, Feb 14, 2018 at 03:31:24PM +, Jean-Marc Lasgouttes wrote:
> Le 13/02/2018 à 00:10, Scott Kostyshak a écrit :
> > > > Does that seem reasonable to you (for 2.3.0)?
> > > 
> > > Yes, I think so. Also because this regression will put pressure on
> > > JMarc for quickly finding a solution ;)
> > 
> > Thanks, sounds good.
> 
> OK, I know nobody cares, but it seems that the issue is not really my fault
> :)

OK now we can tell you that we never thought it was your fault to begin
with. We just wanted you to think that we thought it was your fault. How
else can we get someone to go through the pain of filing a Qt bug
report? :)

Scott


signature.asc
Description: PGP signature


Re: integral upper limit adjacent to integral sign

2018-02-14 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> I took a look at the Qt4 and Qt5 code and did not see a difference. It 
> might be that our fonts are malformed.

I loaded esint10.ttf into fontforge and when I go to Metrics->set L/RBearings
of integral sign (#1) I see the value 113.5.
I doesn't look as what your log stated or do I read it wrong?

Pavel


Re: integral upper limit adjacent to integral sign

2018-02-14 Thread Jean-Marc Lasgouttes

Le 14/02/2018 à 16:50, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

I have tried to run ttfdump on the ttf files, and it shows properly
negative right bearings for both fonts. At this point, I give up :)


Maybe we can try bipartisan attempt on Qt bug tracking system.
I recently filled up the bug for Qt5 not rendering characters
for certain codepoints, maybe we get more attention if we report
this as a part of the bug(?).

https://bugreports.qt.io/browse/QTBUG-66266


I took a look at the Qt4 and Qt5 code and did not see a difference. It 
might be that our fonts are malformed.


JMarc



Re: integral upper limit adjacent to integral sign

2018-02-14 Thread Pavel Sanda
Jean-Marc Lasgouttes wrote:
> I have tried to run ttfdump on the ttf files, and it shows properly 
> negative right bearings for both fonts. At this point, I give up :)

Maybe we can try bipartisan attempt on Qt bug tracking system.
I recently filled up the bug for Qt5 not rendering characters
for certain codepoints, maybe we get more attention if we report
this as a part of the bug(?).

https://bugreports.qt.io/browse/QTBUG-66266

Pavel


Re: integral upper limit adjacent to integral sign

2018-02-14 Thread Jean-Marc Lasgouttes

Le 13/02/2018 à 00:10, Scott Kostyshak a écrit :

Does that seem reasonable to you (for 2.3.0)?


Yes, I think so. Also because this regression will put pressure on
JMarc for quickly finding a solution ;)


Thanks, sounds good.


OK, I know nobody cares, but it seems that the issue is not really my 
fault :) There are issues with our ttf fonts that are beyond my knowledge.


TL;DR: Qt gets the metrics wrong, and I do not know why.

Consider the example file nouveau3.lyx, and instrument LyX with the 
patch showbearings.diff.


With Qt 4.8.7, I get when loading the file (at zoom level 395%)
fantomas: src/lyx ~/nouveau3.lyx
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(1): width=41, Qt 
lbearing=3, Qt rbearing=-5 => 46
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(102): width=20, Qt 
lbearing=-4, Qt rbearing=-8 => 28
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(111): width=32, Qt 
lbearing=2, Qt rbearing=2 => 30



Character 1 is the integral from esint10. Note that the right bearing is 
negative, as it is for the f (102) but not the "o" (111). This is as 
expected.


Now, if I compile against Qt 5.5.1, I get:
fantomas: src/lyx ~/nouveau3.lyx
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(1): width=41, Qt 
lbearing=4, Qt rbearing=4 => 37
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(102): width=20, Qt 
lbearing=-4, Qt rbearing=-8 => 28
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(111): width=32, Qt 
lbearing=2, Qt rbearing=2 => 30


So the 'f' and the 'o' are the same, but the right bearing of the int is 
now positive, which is not good. Remember that negative means that the 
glyph is 'italic' enough to be drawn further than the advance (aka 
cursor position after glyph).



Let's try another font, that is the plain old cmex10. To this end, apply 
the patch cmexint.diff and restart LyX (no compilation needed of course).


With Qt4:
fantomas: src/lyx ~/nouveau3.lyx
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(82): width=40, Qt 
lbearing=-1, Qt rbearing=2 => 38
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(102): width=20, Qt 
lbearing=-4, Qt rbearing=-8 => 28
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(111): width=32, Qt 
lbearing=2, Qt rbearing=2 => 30


With Qt5:
fantomas: src/lyx ~/nouveau3.lyx
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(82): width=40, Qt 
lbearing=-1, Qt rbearing=2 => 38
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(102): width=20, Qt 
lbearing=-4, Qt rbearing=-8 => 28
frontends/qt4/GuiFontMetrics.cpp (166): rbearing(111): width=32, Qt 
lbearing=2, Qt rbearing=2 => 30



So now we have the same result for Qt4 and Qt5 for the \int (now glyph 
82 of cmex10) and this result is incorrect. This leads to faulty 
superscripts for in both cases.


I have tried to run ttfdump on the ttf files, and it shows properly 
negative right bearings for both fonts. At this point, I give up :)


JMarc


nouveau3.lyx
Description: application/lyx
diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp
index b9eab85..2beac64 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -18,6 +18,7 @@
 #include "Dimension.h"
 
 #include "support/convert.h"
+#include "support/debug.h"
 #include "support/lassert.h"
 #include "support/lyxlib.h"
 
@@ -162,6 +163,7 @@ int GuiFontMetrics::rbearing(char_type c) const
 	if (is_utf16(c)) {
 		QChar sc = ucs4_to_qchar(c);
 		value = width(c) - metrics_.rightBearing(sc);
+		LYXERR0("rbearing(" << int(c) << "): width=" << width(c) << ", Qt lbearing=" << metrics_.leftBearing(sc) << ", Qt rbearing=" << metrics_.rightBearing(sc) << " => " << value);
 	} else {
 		// FIXME: QFontMetrics::leftBearing does not support the
 		//full unicode range. Once it does, we could use:
@@ -192,7 +194,7 @@ int GuiFontMetrics::width(docstring const & s) const
 	|| font_.styleName() == "LyX"
 #endif
 	)
-		w = metrics_.width(toqstr(s));
+		w = width(s[0]);
 	else {
 		QTextLayout tl;
 		tl.setText(toqstr(s));
diff --git a/lib/symbols b/lib/symbols
index 31ba7f0..7befc58 100644
--- a/lib/symbols
+++ b/lib/symbols
@@ -1021,33 +1021,33 @@ tbond  cmsy180 186 mathord  x
 # http://www.lyx.org/trac/ticket/1942 for details.
 # If the wasysym integrals are really wanted then one has to load the package
 # manually and disable automatic loading of amsmath and esint.
-iffont esint
-intesint0010  mathop   esint|amsmath
-intop  esint0010  mathop   esint
-iint   esint0030  mathop   esint|amsmath
-iintop esint0030  mathop   esint
-iiint  esint0050  mathop  esint|amsmath
+# iffont esint
+# intesint0010  mathop   esint|amsmath
+# intop  esint0010  mathop   esint
+# iint   esint0030  mathop   esint|amsmath
+# 

Re: integral upper limit adjacent to integral sign

2018-02-13 Thread Scott Kostyshak
On Tue, Feb 13, 2018 at 09:09:22AM +, Jean-Marc Lasgouttes wrote:
> Le 13/02/2018 à 00:10, Scott Kostyshak a écrit :
> > > Yes, I think so. Also because this regression will put pressure on
> > > JMarc for quickly finding a solution ;)
> > 
> > Thanks, sounds good.
> 
> Are you two plotting against me? %-]

Oh shoot that made it to the mailing list? I hope our other messages
were kept private. :)

Scott


signature.asc
Description: PGP signature


Re: integral upper limit adjacent to integral sign

2018-02-13 Thread Jean-Marc Lasgouttes

Le 13/02/2018 à 00:10, Scott Kostyshak a écrit :

Yes, I think so. Also because this regression will put pressure on
JMarc for quickly finding a solution ;)


Thanks, sounds good.


Are you two plotting against me? %-]

JMarc


Re: integral upper limit adjacent to integral sign

2018-02-12 Thread Scott Kostyshak
On Mon, Feb 12, 2018 at 06:53:36PM +, Enrico Forestieri wrote:
> On Mon, Feb 12, 2018 at 11:35:46AM -0500, Scott Kostyshak wrote:
> > On Sat, Feb 10, 2018 at 04:28:49AM +, Scott Kostyshak wrote:
> > 
> > > Whatever Enrico and JMarc decide regarding this for 2.3.0 is fine for
> > > me.
> > 
> > Enrico, JMarc proposed [1] the following:
> > 
> >   I propose to keep the faulty superscript for now and take some time to
> >   determine a satisfactory solution.
> > 
> > Does that seem reasonable to you (for 2.3.0)?
> 
> Yes, I think so. Also because this regression will put pressure on
> JMarc for quickly finding a solution ;)

Thanks, sounds good.

Scott


signature.asc
Description: PGP signature


Re: integral upper limit adjacent to integral sign

2018-02-12 Thread Enrico Forestieri
On Mon, Feb 12, 2018 at 11:35:46AM -0500, Scott Kostyshak wrote:
> On Sat, Feb 10, 2018 at 04:28:49AM +, Scott Kostyshak wrote:
> 
> > Whatever Enrico and JMarc decide regarding this for 2.3.0 is fine for
> > me.
> 
> Enrico, JMarc proposed [1] the following:
> 
>   I propose to keep the faulty superscript for now and take some time to
>   determine a satisfactory solution.
> 
> Does that seem reasonable to you (for 2.3.0)?

Yes, I think so. Also because this regression will put pressure on
JMarc for quickly finding a solution ;)

-- 
Enrico


Re: integral upper limit adjacent to integral sign

2018-02-12 Thread Jean-Marc Lasgouttes

Le 12/02/2018 à 17:35, Scott Kostyshak a écrit :

On Sat, Feb 10, 2018 at 04:28:49AM +, Scott Kostyshak wrote:


Whatever Enrico and JMarc decide regarding this for 2.3.0 is fine for
me.


Enrico, JMarc proposed [1] the following:

   I propose to keep the faulty superscript for now and take some time to
   determine a satisfactory solution.

Does that seem reasonable to you (for 2.3.0)?


FYI, my next step is to try to understand commit 03a4b8c93281 from 
Guillaume.


In particular understand why the kerning is always non-negative
int mathed_char_kerning(FontInfo const & font, char_type c)
{
frontend::FontMetrics const & fm = theFontMetrics(font);
return max(0, fm.rbearing(c) - fm.width(c));
}
but still, there are computations like
min(nker(mi.base.bv), 0)
where nker( is a kerning computed as above.

The fact that Rule 17 from the TeXbook is a pain to read does not help :)

JMarc




Re: integral upper limit adjacent to integral sign

2018-02-12 Thread Scott Kostyshak
On Sat, Feb 10, 2018 at 04:28:49AM +, Scott Kostyshak wrote:

> Whatever Enrico and JMarc decide regarding this for 2.3.0 is fine for
> me.

Enrico, JMarc proposed [1] the following:

  I propose to keep the faulty superscript for now and take some time to
  determine a satisfactory solution.

Does that seem reasonable to you (for 2.3.0)?

Scott


[1] 
https://www.mail-archive.com/search?l=mid=99312227-9c97-da16-797b-469f2dcee655%40lyx.org


signature.asc
Description: PGP signature


Re: integral upper limit adjacent to integral sign

2018-02-09 Thread Scott Kostyshak
On Thu, Feb 08, 2018 at 06:25:46AM +, Scott Kostyshak wrote:
> On Wed, Feb 07, 2018 at 10:56:58AM +, Enrico Forestieri wrote:
> > On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote:
> > > On Tue, Feb 06, 2018 at 10:01:02AM +, Jean-Marc Lasgouttes wrote:
> > > 
> > > > Enrico, for reference this is the commit where we use
> > > > QFontMetrics::width in some cases instead of the QTextLayout thing.
> > > > 
> > > > I tried to revert it and did not see much difference.
> > > 
> > > I tried a vanilla "git revert" on master and there was a conflict so I
> > > did not look further. If you have a patch that reverts it, I could test
> > > that.
> > 
> > Please, try the attached.
> 
> Works well for me.

Whatever Enrico and JMarc decide regarding this for 2.3.0 is fine for
me.

Scott


signature.asc
Description: PGP signature


Re: integral upper limit adjacent to integral sign

2018-02-07 Thread Scott Kostyshak
On Wed, Feb 07, 2018 at 10:56:58AM +, Enrico Forestieri wrote:
> On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote:
> > On Tue, Feb 06, 2018 at 10:01:02AM +, Jean-Marc Lasgouttes wrote:
> > 
> > > Enrico, for reference this is the commit where we use
> > > QFontMetrics::width in some cases instead of the QTextLayout thing.
> > > 
> > > I tried to revert it and did not see much difference.
> > 
> > I tried a vanilla "git revert" on master and there was a conflict so I
> > did not look further. If you have a patch that reverts it, I could test
> > that.
> 
> Please, try the attached.

Works well for me.

Scott


signature.asc
Description: PGP signature


Re: integral upper limit adjacent to integral sign

2018-02-07 Thread Enrico Forestieri
On Wed, Feb 07, 2018 at 12:06:13PM +0100, Jean-Marc Lasgouttes wrote:
> Le 07/02/2018 à 11:56, Enrico Forestieri a écrit :
> > On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote:
> > > On Tue, Feb 06, 2018 at 10:01:02AM +, Jean-Marc Lasgouttes wrote:
> > > 
> > > > Enrico, for reference this is the commit where we use
> > > > QFontMetrics::width in some cases instead of the QTextLayout thing.
> > > > 
> > > > I tried to revert it and did not see much difference.
> > > 
> > > I tried a vanilla "git revert" on master and there was a conflict so I
> > > did not look further. If you have a patch that reverts it, I could test
> > > that.
> > 
> > Please, try the attached.
> > 
> 
> Enrico, is it a matter of taking into account the left/right bearing for
> math symbols? Because this is the difference between naturalWidth and
> horizontalAdvance AFAICS. And this is what I did not try when doing a revert
> "by hand" (see attachment) that did not show any change.

Most probably. Then, I don't know why it is different between Qt4 and Qt5.

-- 
Enrico


Re: integral upper limit adjacent to integral sign

2018-02-07 Thread Jean-Marc Lasgouttes

Le 07/02/2018 à 11:56, Enrico Forestieri a écrit :

On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote:

On Tue, Feb 06, 2018 at 10:01:02AM +, Jean-Marc Lasgouttes wrote:


Enrico, for reference this is the commit where we use
QFontMetrics::width in some cases instead of the QTextLayout thing.

I tried to revert it and did not see much difference.


I tried a vanilla "git revert" on master and there was a conflict so I
did not look further. If you have a patch that reverts it, I could test
that.


Please, try the attached.



Enrico, is it a matter of taking into account the left/right bearing for 
math symbols? Because this is the difference between naturalWidth and 
horizontalAdvance AFAICS. And this is what I did not try when doing a 
revert "by hand" (see attachment) that did not show any change.


JMarc
diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp
index b9eab85..24fa294 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -187,13 +187,13 @@ int GuiFontMetrics::width(docstring const & s) const
 	 * safety measure, always use QMetrics::width with our math fonts.
 	*/
 	int w = 0;
-	if (s.length() == 1
-#if QT_VERSION >= 0x040800
-	|| font_.styleName() == "LyX"
-#endif
-	)
-		w = metrics_.width(toqstr(s));
-	else {
+// 	if (s.length() == 1
+// #if QT_VERSION >= 0x040800
+// 	|| font_.styleName() == "LyX"
+// #endif
+// 	)
+// 		w = metrics_.width(toqstr(s));
+// 	else {
 		QTextLayout tl;
 		tl.setText(toqstr(s));
 		tl.setFont(font_);
@@ -201,7 +201,7 @@ int GuiFontMetrics::width(docstring const & s) const
 		QTextLine line = tl.createLine();
 		tl.endLayout();
 		w = iround(line.horizontalAdvance());
-	}
+//	}
 	strwidth_cache_.insert(s, w, s.size() * sizeof(char_type));
 	return w;
 }


Re: integral upper limit adjacent to integral sign

2018-02-07 Thread Enrico Forestieri
On Tue, Feb 06, 2018 at 12:19:47PM -0500, Scott Kostyshak wrote:
> On Tue, Feb 06, 2018 at 10:01:02AM +, Jean-Marc Lasgouttes wrote:
> 
> > Enrico, for reference this is the commit where we use
> > QFontMetrics::width in some cases instead of the QTextLayout thing.
> > 
> > I tried to revert it and did not see much difference.
> 
> I tried a vanilla "git revert" on master and there was a conflict so I
> did not look further. If you have a patch that reverts it, I could test
> that.

Please, try the attached.

-- 
Enrico
diff --git a/lib/symbols b/lib/symbols
index 31ba7f0eb1..82a6d132d5 100644
--- a/lib/symbols
+++ b/lib/symbols
@@ -314,7 +314,7 @@ spadesuit  cmsy127 170 mathord  
 lyxnot cmsy 54  47 mathrel  /   hiddensymbol
 iffont cmsy
 # kerning is slightly imperfect so that one can see when \not is selected
-\def\not{\lyxnot}
+\def\not{\lyxnot\mathrel{\kern-11mu}}
 else
 \def\not{\kern4mu\lyxnot\kern-19mu}
 endif
@@ -991,11 +991,11 @@ bignplus   stmry 112   0 mathop x  stmaryrd # 
caution: named hugenpl
 
 \def\varcopyright{\mathord{c\kern-11mu\varbigcirc}} stmaryrd
 # kerning is slightly imperfect so that one sees when \[Aa]rrownot is selected
-\def\arrownot{\lyxarrownot} stmaryrd
-\def\Arrownot{\lyxArrownot\mathrel{\kern0.5mu}} stmaryrd
+\def\arrownot{\lyxarrownot\mathrel{\kern-11mu}} stmaryrd
+\def\Arrownot{\lyxArrownot\mathrel{\kern-10.5mu}}   stmaryrd
 \def\longarrownot{\mathrel{\kern5.5mu}\arrownot\mathrel{\kern-5.5mu}} stmaryrd
 \def\Longarrownot{\mathrel{\kern5.5mu}\Arrownot\mathrel{\kern-5.5mu}} stmaryrd
-\def\Mapsto{\Mapstochar\mathrel\Rightarrow}  mathrel  
stmaryrd
+\def\Mapsto{\Mapstochar\mathrel{\kern-2mu}\Rightarrow}   mathrel  
stmaryrd
 \def\mapsfrom{\leftarrow\kern-9mu\mapsfromchar}  mathrel  
stmaryrd
 \def\Mapsfrom{\Leftarrow\kern-9mu\Mapsfromchar}  mathrel  
stmaryrd
 \def\Longmapsto{\Mapstochar\Longrightarrow}  mathrel  
stmaryrd
@@ -1174,7 +1174,7 @@ iffont cmsy
 \def\Longleftarrow{\Leftarrow\joinrel\Relbar}   mathrel 

 \def\implies{\Longrightarrow}   mathrel 
 amsmath
 \def\impliedby{\Longleftarrow}  mathrel 
 amsmath
-\def\mapsto{\mapstochar\rightarrow} mathrel 

+\def\mapsto{\mapstochar\mathrel{\kern-2mu}\rightarrow}  mathrel 

 \def\longmapsto{\mapstochar\joinrel\relbar\joinrel\rightarrow}  mathrel 

 \def\models{\mathrel{\vert}\joinrel\Relbar} mathrel 
 else
diff --git a/src/frontends/qt4/GuiFontMetrics.cpp 
b/src/frontends/qt4/GuiFontMetrics.cpp
index b9eab8531f..43eb4f20e7 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -180,28 +180,16 @@ int GuiFontMetrics::width(docstring const & s) const
PROFILE_THIS_BLOCK(width);
if (strwidth_cache_.contains(s))
return strwidth_cache_[s];
+   // For some reason QMetrics::width returns a wrong value with Qt5
+   // int w = metrics_.width(toqstr(s));
PROFILE_CACHE_MISS(width);
-   /* For some reason QMetrics::width returns a wrong value with Qt5
-* with some arabic text. OTOH, QTextLayout is broken for single
-* characters with null width (like \not in mathed). Also, as a
-* safety measure, always use QMetrics::width with our math fonts.
-   */
-   int w = 0;
-   if (s.length() == 1
-#if QT_VERSION >= 0x040800
-   || font_.styleName() == "LyX"
-#endif
-   )
-   w = metrics_.width(toqstr(s));
-   else {
-   QTextLayout tl;
-   tl.setText(toqstr(s));
-   tl.setFont(font_);
-   tl.beginLayout();
-   QTextLine line = tl.createLine();
-   tl.endLayout();
-   w = iround(line.horizontalAdvance());
-   }
+   QTextLayout tl;
+   tl.setText(toqstr(s));
+   tl.setFont(font_);
+   tl.beginLayout();
+   QTextLine line = tl.createLine();
+   tl.endLayout();
+   int w = int(line.naturalTextWidth());
strwidth_cache_.insert(s, w, s.size() * sizeof(char_type));
return w;
 }


Re: integral upper limit adjacent to integral sign

2018-02-06 Thread Jean-Marc Lasgouttes

Le 01/02/2018 à 06:20, Scott Kostyshak a écrit :

On Wed, Jan 31, 2018 at 11:41:58PM +, Jean-Marc Lasgouttes wrote:


For the rest, it is probably the complete rewrite of math spacing...
But a bisect may prove useful.


Bisect leads to 4a935ed7.


Are you sure? Enrico, for reference this is the commit where we use 
QFontMetrics::width in some cases instead of the QTextLayout thing.


I tried to revert it and did not see much difference. What I can tell 
though is that the situation is qt5-only.


JMarc


Re: integral upper limit adjacent to integral sign

2018-01-31 Thread Jean-Marc Lasgouttes

Le 31/01/2018 à 23:26, Scott Kostyshak a écrit :

There seems to have been two changes, compared to 2.2.x, regarding the
LyX display of the integral sign and its limits. In 2_2016-12-04.png,
the upper limit is now vertically aligned with the bottom limit. In
current 2.3.x, the limits are moved to the left to the point where the
upper limit is adjacent to integral.

I find the appearance of 2.2.x to be closest to the PDF output.

I can do a bisect (for one or both of the above changes) if that would
help. I didn't do that yet since I don't know if this change was
intended.


65a6cc1fc3bc71a is a good candidate for the change between 2.2.x and Dec 
2016.


For the rest, it is probably the complete rewrite of math spacing...
But a bisect may prove useful.

We have a notion of kerning (I think) that can make alignment different 
between sub and superscript. But Guillaume is the person who knows about 
that, not me.


JMarc



Re: integral upper limit adjacent to integral sign

2018-01-31 Thread Scott Kostyshak
On Wed, Jan 31, 2018 at 10:26:31PM +, Scott Kostyshak wrote:
> There seems to have been two changes, compared to 2.2.x, regarding the
> LyX display of the integral sign and its limits. In 2_2016-12-04.png,
> the upper limit is now vertically aligned with the bottom limit. In
> current 2.3.x, the limits are moved to the left to the point where the
> upper limit is adjacent to integral.
> 
> I find the appearance of 2.2.x to be closest to the PDF output.
> 
> I can do a bisect (for one or both of the above changes) if that would
> help. I didn't do that yet since I don't know if this change was
> intended.
> 
> Scott

Attached is also the corresponding example .lyx file.

Scott


integral.22.lyx
Description: application/lyx


signature.asc
Description: PGP signature