Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
chrissimpkins opened this issue Apr 7, 2016 · 13 comments
Labels

Comments

@chrissimpkins
Copy link
Member

reported by @alphapapa in source-foundry/Hack#191 (comment):

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
Copy link
Member Author

@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
Copy link

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link

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
Copy link
Member Author

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

@chrissimpkins
Copy link
Member Author

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
Copy link
Member Author

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
Copy link

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
Copy link
Member Author

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

@alphapapa
Copy link

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
Copy link
Member Author

great to hear that! enjoy it

@chrissimpkins
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants