[LyX/master] Implement variable size bigops

[Enrico Forestieri]

On Tue, Jul 21, 2020 at 11:12:33PM +0200, Enrico Forestieri wrote:
> On Sat, Jul 18, 2020 at 12:01:16AM +0200, Jean-Marc Lasgouttes wrote:
> > Le 17/07/2020 à 23:40, Enrico Forestieri a écrit :
> > > On Fri, Jul 17, 2020 at 10:32:09PM +0200, Jean-Marc Lasgouttes wrote:
> > > > 
> > > > This is something that has been bugging me for some time. Look at the file
> > > > in attachment to see what the effect is.
> > > 
> > > Yes, it looks better. However, it also makes more evident that the
> > > lower limit of an integral is badly placed. In general, the limits
> > > of an integral were better placed until lyx 2.2 and somewhat broken
> > > starting from 2.3.
> > 
> > I will try to check older versions. I broke something, but what? Could it be
> > also a matter of Qt or freetype version?
> 
> I made the following experiment. After applying the attached patch to
> the lyx 2.2 sources, I compiled them using Qt 5.15.0. Then replaced
> the esint10.ttf font with the current one in master. Thus, I was using
> the same ttf font and Qt version. Then I loaded the attached document
> in lyx 2.2 and current master (compiled after applying the debugging patch
> to MathSupport.cpp). I got the following results.
> 
> lyx 2.2:
> code: 2, lbearing: 1, rbearing: 22, width: 13, kerning: 9
> 
> current master:
> code: 2, lbearing: 0, rbearing: 10, width: 10, kerning: 0

The above results were obtained on Windows. The following ones, which are
even more disconcerting, on linux.

lyx-2.2
code: 2, lbearing: 1, rbearing: 28, width: 16, kerning: 12

current master:
code: 2, lbearing: 0, rbearing: 0, width: 7, kerning: 0

> I wonder why the metrics are so different given that both Qt and
> the ttf font are the same. Needless to say that the limits are
> perfectly placed in lyx 2.2 and misplaced in current master.

I think the answer to the previous question is that the metrics on master
do not refer to the correct font.

After applying the attached patches to lyx 2.2 and current master, and
loading the document attached to the previous email, I get the following.

lyx-2.2:
caching width: 10, code: 73, family: TeX Gyre Termes
caching width: 13, code: 120, family: TeX Gyre Termes
caching width: 16, code: 2, family: esint10
caching width: 7, code: 73, family: TeX Gyre Termes
caching width: 9, code: 120, family: TeX Gyre Termes
caching width: 10, code: 49, family: TeX Gyre Termes
caching width: 10, code: 48, family: TeX Gyre Termes

current master:
caching width: 8, code: 73, family: TeX Gyre Termes
caching strwidth: 13, code: 2, family: esint10
caching width: 7, code: 2, family: TeX Gyre Termes
caching width: 6, code: 73, family: TeX Gyre Termes
caching width: 8, code: 49, family: TeX Gyre Termes
caching width: 8, code: 48, family: TeX Gyre Termes
caching strwidth: 8, code: 49, family: TeX Gyre Termes
caching strwidth: 8, code: 48, family: TeX Gyre Termes

As you can see, in the current master case, the width 7 comes from
the codepoint 2 of the "TeX Gyre Termes" font, not esint10.
It can also be seen that in 2.2 the strwidth cache never comes into
play, contrarily to the current master case.

So, the question is why in current master the metrics of the wrong
font are used? I don't have an answer.

-- 
Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug-22x.diff
Type: text/x-diff
Size: 2042 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200722/f1a68b38/attachment-0002.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug-24x.diff
Type: text/x-diff
Size: 1201 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200722/f1a68b38/attachment-0003.diff>