Re: integral upper limit adjacent to integral sign
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
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
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 Lasgouttesa é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
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 LasgouttesDate: 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
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
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
Le 15 février 2018 16:32:23 GMT+01:00, Jean-Marc Lasgouttesa é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
Le 15 février 2018 16:23:16 GMT+01:00, Pavel Sandaa é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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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