From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/110313 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mikael Sundqvist Newsgroups: gmane.comp.tex.context Subject: Re: LMTX isn't typesetting math correctly with Pagella Date: Mon, 18 Jan 2021 21:18:54 +0100 Message-ID: References: <5aba5c47-12b5-5a07-193f-063c75405389@gmail.com> <00e04880-8856-4535-903f-92c275ae2946@xs4all.nl> Reply-To: mailing list for ConTeXt users Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8875586035351711244==" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18322"; mail-complaints-to="usenet@ciao.gmane.io" To: mailing list for ConTeXt users Original-X-From: ntg-context-bounces@ntg.nl Mon Jan 18 21:19:38 2021 Return-path: Envelope-to: gctc-ntg-context-518@m.gmane-mx.org Original-Received: from zapf.boekplan.nl ([5.39.185.232] helo=zapf.ntg.nl) by ciao.gmane.io with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1azy-0004fI-Pa for gctc-ntg-context-518@m.gmane-mx.org; Mon, 18 Jan 2021 21:19:38 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by zapf.ntg.nl (Postfix) with ESMTP id A1F461C1EEE; Mon, 18 Jan 2021 21:19:24 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at zapf.boekplan.nl Original-Received: from zapf.ntg.nl ([127.0.0.1]) by localhost (zapf.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j24Ul5A6VjWM; Mon, 18 Jan 2021 21:19:23 +0100 (CET) Original-Received: from zapf.ntg.nl (localhost [127.0.0.1]) by zapf.ntg.nl (Postfix) with ESMTP id A96611C1F28; Mon, 18 Jan 2021 21:19:23 +0100 (CET) Original-Received: from localhost (localhost [127.0.0.1]) by zapf.ntg.nl (Postfix) with ESMTP id 96BE41C1F3B for ; Mon, 18 Jan 2021 21:19:22 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at zapf.boekplan.nl Original-Received: from zapf.ntg.nl ([127.0.0.1]) by localhost (zapf.ntg.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF4sdWqdrh5O for ; Mon, 18 Jan 2021 21:19:21 +0100 (CET) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.218.42; helo=mail-ej1-f42.google.com; envelope-from=mickep@gmail.com; receiver= Original-Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by zapf.ntg.nl (Postfix) with ESMTPS id D926B1C1EE2 for ; Mon, 18 Jan 2021 21:19:21 +0100 (CET) Original-Received: by mail-ej1-f42.google.com with SMTP id g3so6034885ejb.6 for ; Mon, 18 Jan 2021 12:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jjm6AZsG0v4YIE9q/y6nnpj5h/6PU0e2VruyJeR5Wtc=; b=j9abFtvui4mSg9fx6VEaJv88xgkgyX580ZxOZJlFP5kUmfX5CWMDI8o3Qz6gjmo6rA qhlhPwlYE2R0TqhIlKngdcne5lSlLN02dyTK4Tw/a0qA7UfX80cJcwT5T0Z7/yc0JonH yKTisngafCqmA9fEgJqaEYyGwUi2S0su3FiPn2aU8Bjc3HgrTQgw64yPeHkPcZiHUcET biSHsqys6jYcnM6XJk0107gY9LFN8L5MFdKNYBLDn9xwCPRxFRAS95Gxl8cF+pXoiW7r sscm9EbR8xtoM28WxdOZvYCIEaAXBXl1ml9r6YayeR3h+2cdcTsSXUSmi4VszTNZrdTn NlwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jjm6AZsG0v4YIE9q/y6nnpj5h/6PU0e2VruyJeR5Wtc=; b=OdpxVCWZTrK9To1iZlaqYRPbeNmEd3wF1zIYsY/EdCe52ECuWye7ul0YkN4vVgC1QR i6kNpvrDdz5eHXaVJzlT2dSU8xAv6OQVRu4EJYvLu7jbbVXHoZdEASasvyrzou9W7k5t TP0iwhESJ+5hsLejGdi1RC+NQgXkW8SJhYpdr89nan5WU9q9Wqa35lTVVFsQMdk4yh20 PBc2UtCjZxYWxIIL4yglSezAh035EFWWuuojgmyBYTJwv/nBsE4dluAP4CF716VTbuYn 6X8YxDe8V0EyNGABWZx0EYvA4b8+7/xhIWsL4XVj1KrT5phz1acYVLz6w+Z/oTVKGWUC XoYA== X-Gm-Message-State: AOAM532hJQx5dG4q6HSqvE6UAoz6C2teBS4iDGZqsNYD+AYc4yyFysMQ 9pO+xiQeQMfF8MMSsgkDCkaqYP+m1wfZ9yLBdquEVRcMsV4= X-Google-Smtp-Source: ABdhPJzxCjRuxeO/UCUvyg8Jiot6FTvgr5XurRpOhwBEPn9GQfx3PjWomw7R2X9cUuLvMRVcVANBLsDAMflQHxNgRhg= X-Received: by 2002:a17:906:780c:: with SMTP id u12mr850121ejm.125.1611001161080; Mon, 18 Jan 2021 12:19:21 -0800 (PST) In-Reply-To: <00e04880-8856-4535-903f-92c275ae2946@xs4all.nl> X-BeenThere: ntg-context@ntg.nl X-Mailman-Version: 2.1.26 Precedence: list List-Id: mailing list for ConTeXt users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ntg-context-bounces@ntg.nl Original-Sender: "ntg-context" Xref: news.gmane.io gmane.comp.tex.context:110313 Archived-At: --===============8875586035351711244== Content-Type: multipart/alternative; boundary="000000000000f0651d05b9326faa" --000000000000f0651d05b9326faa Content-Type: text/plain; charset="UTF-8" On Sun, Jan 17, 2021 at 10:00 PM Hans Hagen wrote: > On 1/16/2021 12:33 AM, Hans Hagen wrote: > > On 1/15/2021 1:33 PM, Jack Hill wrote: > >> Hi, > >> > >> I've been having some trouble with ConTeXt not typesetting math > >> correctly when using the Pagella font (I do not know if the same issue > >> occurs with other fonts as I haven't tested them). > >> > >> If I compile with LMTX, the spacing between letters becomes very small > >> so that when I type "|f|", for example, the second "|" intersects the > >> f and looks rather ugly. However, compiling with the --luatex switch > >> fixes these issues and the math looks nice again. > >> > >> Can anybody else replicate this issue, and does anybody know why it is > >> happening? > >> > >> This the code I used to test: > >> > >> |\setupbodyfont[pagella] \starttext \startformula |f| = \sqrt{\int_0^1 > >> |f(t)|^2 \text{d}t} \stopformula \stoptext ||| > > I'll check it ... smells like some interference between newer and older > > corrections (these gyre fonts need some special treatment). > I uploaded lmtx. > > Here is the story about math: > > - there is traditional math, the 8 bit fonts (from Don Knuth) > - and there is opentype math (originating at Microsoft) > > the eight bit fonts are all modelled after the cmr fonts so they have > the same set of parameters, the same assumptions about family 2 and 3, > use the same width/height/depth trickery > > one thing is that they lie about the width: the italic correction is > subtracted from the width and the engine always adds it when a glyph is > dealt with but then removes in some cases afterwards > > in opentype we also have italic correction but that is applied in > specific cases; there the shapes have a real width > > (there are tricks to make fonts seen as opentype be treated as old > school which work ok for virtual constructs that only use those 8 bit > fonts but often fail for gyre fonts) > > now, the gust foundation fonts are a mix: they are opentype, have its > parameters and properties but have the wrong width and assume the italic > hackery > > the microsoft cambria font is the reference for opentype math (and to > some extend microsoft word also is) > > afaik xetex uses the old tex approach also for opentype so that is why > probably the old width approach works ok there but i never looked into > it; cambria is an opentype font but probably seldom used so side effects > will go unnoticed, also, texies often have no problem blaming microsoft, > even when they got it right; of course we have to admit that 'moving > forward wrt math fonts' didn't come from our community so we just have > to follow > > now, when we move on (with context + luametatex) to a variants font > scaling model, i need to adapt the math machinery to deal with that ... > this can have side effects as you noticed but these will be dealt with > (or fixed when something is wrong) > > in context we have font goodies that can handle this (widths, kerns etc) > and we do so for at least the 'f' which also has a strange left offset > ... i now adapted that to also serve the new (compact context font) > model and also make sure that the smaller sizes for mkiv are handled; we > can add more in those files, but that's also a (math) user effort > > to be decided is of we use the feature setting "mathkerns=yes" (this was > a directive but i made it just a feature) > > Now, ideally: > > \enableexperiments[fonts.compact] % for the definitions > > should give nearly similar results (but less mem usage, less fonts > loaded and possibly some performance gain) > > I also updated some test features: > > \definefontfeature[mathextra][staircase=yes,boundingbox=frame] > > as part of the general lmtx upgrading process. Only cambria (and lucida) > have these staircase kerns and e.g. pagella and friends have a few > defined in the font goodies but one has to do something liek this: > > > > \definefontfeature[mathextra][mathkerns=yes,staircase=yes,boundingbox=frame] > > more such tracers will be added in due time (and some old ones will go > away as they lost their purpose). > > Hans > > I got curious about those staircase kerns. Is there a simple example that shows their effect? I greped the source, but did not find anything where I could see a difference. /Mikael --000000000000f0651d05b9326faa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jan 17, 2021 at 10:00 PM Hans Hag= en <j.hagen@xs4all.nl> wrote= :
On 1/16/2021 12:33 AM, Hans Hagen wrote:
> On 1/15/2021 1:33 PM, Jack Hill wrote:
>> Hi,
>>
>> I've been having some trouble with ConTeXt not typesetting mat= h
>> correctly when using the Pagella font (I do not know if the same i= ssue
>> occurs with other fonts as I haven't tested them).
>>
>> If I compile with LMTX, the spacing between letters becomes very s= mall
>> so that when I type "|f|", for example, the second "= ;|" intersects the
>> f and looks rather ugly. However, compiling with the --luatex swit= ch
>> fixes these issues and the math looks nice again.
>>
>> Can anybody else replicate this issue, and does anybody know why i= t is
>> happening?
>>
>> This the code I used to test:
>>
>> |\setupbodyfont[pagella] \starttext \startformula |f| =3D \sqrt{\i= nt_0^1
>> |f(t)|^2 \text{d}t} \stopformula \stoptext |||
> I'll check it ... smells like some interference between newer and = older
> corrections (these gyre fonts need some special treatment).
I uploaded lmtx.

Here is the story about math:

- there is traditional math, the 8 bit fonts (from Don Knuth)
- and there is opentype math (originating at Microsoft)

the eight bit fonts are all modelled after the cmr fonts so they have
the same set of parameters, the same assumptions about family 2 and 3,
use the same width/height/depth trickery

one thing is that they lie about the width: the italic correction is
subtracted from the width and the engine always adds it when a glyph is dealt with but then removes in some cases afterwards

in opentype we also have italic correction but that is applied in
specific cases; there the shapes have a real width

(there are tricks to make fonts seen as opentype be treated as old
school which work ok for virtual constructs that only use those 8 bit
fonts but often fail for gyre fonts)

now, the gust foundation fonts are a mix: they are opentype, have its
parameters and properties but have the wrong width and assume the italic hackery

the microsoft cambria font is the reference for opentype math (and to
some extend microsoft word also is)

afaik xetex uses the old tex approach also for opentype so that is why
probably the old width approach works ok there but i never looked into
it; cambria is an opentype font but probably seldom used so side effects will go unnoticed, also, texies often have no problem blaming microsoft, even when they got it right; of course we have to admit that 'moving forward wrt math fonts' didn't come from our community so we just h= ave
to follow

now, when we move on (with context + luametatex) to a variants font
scaling model, i need to adapt the math machinery to deal with that ... this can have side effects as you noticed but these will be dealt with
(or fixed when something is wrong)

in context we have font goodies that can handle this (widths, kerns etc) and we do so for at least the 'f' which also has a strange left off= set
... i now adapted that to also serve the new (compact context font)
model and also make sure that the smaller sizes for mkiv are handled; we can add more in those files, but that's also a (math) user effort

to be decided is of we use the feature setting "mathkerns=3Dyes" = (this was
a directive but i made it just a feature)

Now, ideally:

=C2=A0 =C2=A0 \enableexperiments[fonts.compact] % for the definitions

should give nearly similar results (but less mem usage, less fonts
loaded and possibly some performance gain)

I also updated some test features:

=C2=A0 =C2=A0 \definefontfeature[mathextra][staircase=3Dyes,boundingbox=3Df= rame]

as part of the general lmtx upgrading process. Only cambria (and lucida) have these staircase kerns and e.g. pagella and friends have a few
defined in the font goodies but one has to do something liek this:


\definefontfeature[mathextra][mathkerns=3Dyes,staircase=3Dyes,boundingbox= =3Dframe]

more such tracers will be added in due time (and some old ones will go
away as they lost their purpose).

Hans


I got curious about those stai= rcase kerns. Is there a simple example that shows their effect? I greped th= e source, but did not find anything where I could see a difference.

/Mikael=C2=A0
--000000000000f0651d05b9326faa-- --===============8875586035351711244== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KSWYgeW91ciBxdWVzdGlvbiBpcyBvZiBpbnRlcmVz dCB0byBvdGhlcnMgYXMgd2VsbCwgcGxlYXNlIGFkZCBhbiBlbnRyeSB0byB0aGUgV2lraSEKCm1h aWxsaXN0IDogbnRnLWNvbnRleHRAbnRnLm5sIC8gaHR0cDovL3d3dy5udGcubmwvbWFpbG1hbi9s aXN0aW5mby9udGctY29udGV4dAp3ZWJwYWdlICA6IGh0dHA6Ly93d3cucHJhZ21hLWFkZS5ubCAv IGh0dHA6Ly9jb250ZXh0LmFhbmhldC5uZXQKYXJjaGl2ZSAgOiBodHRwczovL2JpdGJ1Y2tldC5v cmcvcGhnL2NvbnRleHQtbWlycm9yL2NvbW1pdHMvCndpa2kgICAgIDogaHR0cDovL2NvbnRleHRn YXJkZW4ubmV0Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCg== --===============8875586035351711244==--