Skip to content
This repository has been archived by the owner on Sep 27, 2019. It is now read-only.

Change in fontdimen8 in luaotfload 2.7 #358

Closed
jeremy-engel opened this issue May 7, 2016 · 1 comment
Closed

Change in fontdimen8 in luaotfload 2.7 #358

jeremy-engel opened this issue May 7, 2016 · 1 comment

Comments

@jeremy-engel
Copy link

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.)

@phi-gamma
Copy link
Member

···<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.

Philipp

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants