You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 27, 2019. It is now read-only.
I am testing TeX Live 2016 with luaotfload 2.7-fix-2. I cam across an issue with a proprietary font, but the issue seems to be more general.
Consider the example below:
\input luaotfload.sty
\font\testfont = {name:Gotham} at 10pt
\the\fontdimen5\testfont\the\fontdimen8\testfont\bye
In this example in TeX Live 2015 with luaotfload 2.6-fix-6, the fontdimen 5 and 8 values are 5.17pt and 7.0pt. In TeX Live 2016 with luaotfload 2.7-fix-2, the values are 5.17pt and 5242.88pt.
Look at the recent changes for how fontdimen8 is set, it looks like the values of query_capheight, query_ascender, and determine_capheight are used if found, in that order. For this font (Gotham), those three values are false, 343597383.68, and 458752. The query_ascender value seems to be scaled improperly.
I checked TeX Gyre Termes as well and found the values to be 433848.32, 336295939.2768, and 433848.32, so it looks like the scale issue with the query_ascender method is not font-specific.
(I'll note that I came across this behavior when using the Scale=MatchUppercase feature of fontspec which uses fontdimen8. The text was about 1/500 of the expected size.)
The text was updated successfully, but these errors were encountered:
···<date: 2016-05-07, Saturday>···<from: Jeremy Engel>···
I am testing TeX Live 2016 with luaotfload 2.7-fix-2. I cam
across an issue with a proprietary font, but the issue seems to
be more general.
Good catch, thanks for reporting. There’s a free font that
exhibits the same behavior, GFS Didot.
I checked TeX Gyre Termes as well and found the values to be 433848.32, 336295939.2768, and 433848.32, so it looks like
the scale issue with the query_ascender method is not
font-specific.
The old fontloader pre-scaled some of the values for us that the
new one leaves untouched. In the case at hand the spec
seems to indicate that the “typographic ascender” should be unit
scaled before usage. This doesn’t seem to be true for the
parameters table, I’ll remove the scaling.
I am testing TeX Live 2016 with luaotfload 2.7-fix-2. I cam across an issue with a proprietary font, but the issue seems to be more general.
Consider the example below:
In this example in TeX Live 2015 with luaotfload 2.6-fix-6, the fontdimen 5 and 8 values are 5.17pt and 7.0pt. In TeX Live 2016 with luaotfload 2.7-fix-2, the values are 5.17pt and 5242.88pt.
Look at the recent changes for how fontdimen8 is set, it looks like the values of
query_capheight
,query_ascender
, anddetermine_capheight
are used if found, in that order. For this font (Gotham), those three values arefalse
,343597383.68
, and458752
. Thequery_ascender
value seems to be scaled improperly.I checked TeX Gyre Termes as well and found the values to be
433848.32
,336295939.2768
, and433848.32
, so it looks like the scale issue with thequery_ascender
method is not font-specific.(I'll note that I came across this behavior when using the
Scale=MatchUppercase
feature offontspec
which usesfontdimen8
. The text was about 1/500 of the expected size.)The text was updated successfully, but these errors were encountered: