source-foundry / font-line

OpenType vertical metrics reporting and font line spacing adjustment tool
184 stars 11 forks source link

Percent command does not properly calculate line spacing when fonts define TypoAscender + TypoDescender > UPM #6

Closed chrissimpkins closed 8 years ago

chrissimpkins commented 8 years ago

reported by @alphapapa in https://github.com/chrissimpkins/Hack/issues/191#issuecomment-206601705:

Hey Chris,

I just tried the 15% command, but it increased the line spacing instead of reducing it:

$ font-line report FiraCode-Regular.otf 

=== FiraCode-Regular.otf ===
Version 1.102;PS 001.102;hotconv 1.0.88;makeotf.lib2.5.64775
SHA1: 87fda07094d49978382399e0532b021ef8fb6b02

--- Metrics ---
[head] Units per Em:    1000
[head] yMax:            1050
[head] yMin:            -500
[OS/2] TypoAscender:    935
[OS/2] TypoDescender:   -265
[OS/2] WinAscent:       935
[OS/2] WinDescent:      265
[hhea] Ascent:          935
[hhea] Descent:         -265

[hhea] LineGap:         0
[OS/2] TypoLineGap:     0

--- Height Calculations by Table Values ---
[OS/2] TypoAscender to TypoDescender:   1200
[OS/2] WinAscent to WinDescent:         1200
[hhea] Ascent to Descent:               1200

--- Delta Values ---
WinAscent to TypoAscender:      0
Ascent to TypoAscender:         0
WinDescent to TypoDescender:    0
Descent to TypoDescender:       0

--- Ratios ---
(Typo Asc + Desc + Linegap) / UPM:      1.2
(winAsc + winDesc) / UPM:               1.2
(hhea Asc + Desc) / UPM:                1.2

$ font-line percent 15 FiraCode-*.otf
[font-line] 'FiraCode-Bold.otf' successfully modified to 'FiraCode-Bold-linegap15.otf'.
[font-line] 'FiraCode-Regular.otf' successfully modified to 'FiraCode-Regular-linegap15.otf'.

$ font-line report FiraCode-Regular-linegap15.otf 

=== FiraCode-Regular-linegap15.otf ===
Version 1.102;PS 001.102;hotconv 1.0.88;makeotf.lib2.5.64775
SHA1: 269660e4c91ed4de6c91f7823514c4cafe4d3a93

--- Metrics ---
[head] Units per Em:    1000
[head] yMax:            1050
[head] yMin:            -500
[OS/2] TypoAscender:    935
[OS/2] TypoDescender:   -265
[OS/2] WinAscent:       1025
[OS/2] WinDescent:      355
[hhea] Ascent:          1025
[hhea] Descent:         -355

[hhea] LineGap:         0
[OS/2] TypoLineGap:     180

--- Height Calculations by Table Values ---
[OS/2] TypoAscender to TypoDescender:   1200
[OS/2] WinAscent to WinDescent:         1380
[hhea] Ascent to Descent:               1380

--- Delta Values ---
WinAscent to TypoAscender:      90
Ascent to TypoAscender:         90
WinDescent to TypoDescender:    90
Descent to TypoDescender:       90

--- Ratios ---
(Typo Asc + Desc + Linegap) / UPM:      1.38
(winAsc + winDesc) / UPM:               1.38
(hhea Asc + Desc) / UPM:                1.38

Then I uninstalled the original version of the fonts, installed the new fonts, and restarted Emacs, and the line spacing is indeed increased.

chrissimpkins commented 8 years ago

@alphapapa

Will modify the calculations to address this issue. We had a discussion about the line spacing approaches in #2 and the Fira approach is one that was discussed (and recommended) there. I will be able to support modifications in fonts that use these metrics. Should be a reasonably simple fix. Will let you know when it is available in this thread.

alphapapa commented 8 years ago

Ah, yes, I saw that thread. I didn't realize how complicated and non-cross-platform line-spacing metrics are. Web fonts don't help the situation, do they? haha

Thanks for your work on this. I was particularly inspired when you said:

I understand that this is, perhaps, unacceptable from a design purist standpoint but I would like to try to develop a strategy that empowers users to make the typeface more usable/functional for themselves in situations where editors do not permit line spacing adjustments.

It's refreshing to hear a knowledgeable and capable developer express such a user-focused point of view today. It seems to be more and more rare, with most software being inclined to capture users rather than empower them.

Let me know if you ever decide to start a Web browser project... (half kidding...)

chrissimpkins commented 8 years ago

how complicated and non-cross-platform line-spacing metrics are

Yes! Frustratingly so...

user-focused point of view...

I make tools that I want/need and use everything that I make so I am very user-focused :)

if you ever decide to start a Web browser project...

lol 😊🔫

chrissimpkins commented 8 years ago

Your issue is fixed as of v0.6.0. It is now live on PyPI and in the master branch of the repository.

You can upgrade with:

$ pip install --upgrade font-line

I tested the changes on FiraMono which has the same metrics as FiraCode. You should be able to increase and decrease line spacing by the %UPM value defined on the command line now.

Let me know if you still see any problems after the update.

Enjoy!

alphapapa commented 8 years ago

Hi Chris,

I tested the new version and the metric adjustments work fine. It's nice to have those few extra lines!

However, I noticed that the glyphs look a bit different in the modified font. They don't look bad, but they appear thinner. Is this expected? I've attached screenshots. Here's the original:

fira-code-original

And here's the modified 1.15 version:

fira-code-15

I also noticed that the line-spacing appears inconsistent. For example, in the let*, where the vars positive-re, positive-re-list, and context-re are defined, the middle line is closer to the line below it than the line above it by 1-2 pixels.

Is this something like a rounding error or a lack of precision? Would using different metrics adjust more cleanly?

Thanks for your work on this.

chrissimpkins commented 8 years ago

Will take a look this weekend. Will let you know.

chrissimpkins commented 8 years ago

I am having a difficult time making out the issues that you describe in the screenshots. Unclear to me why you would be seeing thinner strokes in the glyphs with these changes. As for the line spacing issue, I wonder if emacs accounts for spacing between lines based upon the size of glyphs in a given line. This might be a way to prevent clipping of parts of the glyphs that span across your tighter line spacing. Does this seem to be happening only in cases where there are glyphs present that extend below the baseline? Have a look for lines that include the lowercase g since it will tend to be one that spans the lowest in the ASCII set.

Are you seeing these issues in other editors?

chrissimpkins commented 8 years ago

Actually, just noticed that this does not seem to be the same typeface in the two images! Check the lowercase g glyph. They are different in the two sets.

alphapapa commented 8 years ago

Wow, that's a facepalm-fail on my part. Apparently, after installing the new font and restarting Emacs, I forgot to actually select the new font in Emacs. And then I didn't look closely enough at the screenshots I took to notice. Sorry for wasting your time on this. :(

chrissimpkins commented 8 years ago

No worries! Let me know if it worked out in the modified fonts.

alphapapa commented 8 years ago

Hey Chris,

I just tested it again and it's looking great! I modified Fira Code from the default 1.2 to 1.15, and I gained 4 extra lines of text in Emacs, and all the glyphs appear to look the same. I've attached screenshots.

Thanks for your work on this! This will make several fonts usable for me, ones where the default line spacing simply is too large.

fira-code-20 fira-code-15

chrissimpkins commented 8 years ago

great to hear that! enjoy it

chrissimpkins commented 8 years ago

Will close this. Feel free to reopen if you have any other problems with it.