Line height vastly different in OTF vs. TTF

[alerque]

I discovered one of the major reasons I like the way OTF runs on my system in that the leading actually works out to be quite a bit bigger for the same text size. I assume this is an issue with the build process and as development has focused on the TTF versions to date that those are "correct" and the OTF is out of whack.

But here's the thing: I think the resulting line height in the OTF is preferable and would not want to see the OTF "fixed" to match. Instead I would go the other way and expand the line height in the TTF version.

Has expanding the line height a touch been considered? Is it possible to fix?

[MarkusKull]

The larger line-height of OTF always seemed intended to me: "The large x-height + wide aperture + low contrast design combined with PostScript hinting/hint replacement programs and a TrueType instruction set make it highly legible at commonly used source code text".
I prefer the larger OTF over TTF. Unfortunately no Windows available for a side-by-side comparison with Linux.

[chrissimpkins]

Recommendations about line spacing (i.e. space between two rows of glyphs) have been all over the place. We originally began with a wider line spacing and it narrowed over the first few iterations of the v2.x font releases. There are some who would like to see it tighter still and others who have requested more default spacing between lines.

It's a very subjective issue and there will not be a one size fits all solution. Some want to pack as many possible lines of code into a given view (there was a comment that one person wanted it "clown car tight" :) ), others want greater legibility associated with more whitespace between rows of characters. With typesetting, this isn't an issue because you can define it however you would like, irrespective of the font defaults. It's not the case for many/most source code text editors which creates the issue.

I've kicked this around for some time and what I intend to do is provide a script that allows you to define the spacing for yourself in the fonts. This will work in both directions so that you can modify the defaults either tighter or looser based upon your platform/editor combination. We've had the discussion about releasing separate (from the main release builds) builds that include tighter and looser spacing defaults, but I think that this will be the most flexible approach. If there are a couple of tighter and looser variant specs that seem to be in common use, then perhaps we could consider including these changes as part of the build workflow.

Any default vertical spacing changes create issues for the fonts that are very time consuming to correct. Anything that requires exact vertical spacing relationships across different lines (including the box drawing glyphs and block element glyphs) will no longer maintain these relationships with these adjustments. This has been part of my hesitation with the multi-variant releases because we are still working on the spacing / orientation of these vertical positions in the main font set. Take this into consideration once this script is released if you commonly use these glyphs in the body of text where you use Hack.

@MarkusKull Markus, the x-height is a different property of the fonts. This is the ~height of the lowercase glyphs in the sets (approximate because many lowercase glyphs extend beyond the baseline or above the x-height 'line', the x is a good measure because it has horizontal lines at the top and bottom of the strokes that are used to create the glyph). With larger x-heights, the lowercase glyphs are larger. This design feature is felt to improve legibility because it "opens up" features of these lowercase shapes that can become difficult to visualize in poor viewing conditions. This includes situations like road signs (in bad weather) and screen use, particularly at small text sizes commonly used for source code. https://en.wikipedia.org/wiki/X-height

[psycha0s]

Could you please provide some info how to correctly increase the line spacing? I've changed the following OS/2 metrics with FontForge and got a good result, but for some strange reason, bold glyphs became much bolder:
Win Ascent 1901 -> 2101
Win Descent 483 -> 683
Typo Line Gap 410 -> 736
HHead Ascent 1901 -> 2101
HHead Descent -483 -> -683

TBH, these values are very incomprehensible for me and AFAIK, different OSes interpret them differently.

[chrissimpkins]

@Phantom-code What platform are you on?

[psycha0s]

@chrissimpkins Linux, freetype infinality

[chrissimpkins]

@Phantom-code It's unfortunately not a straightforward issue Anton and you are correct that the vertical metrics differ by platform. Here is some background to get you started:

https://www.glyphsapp.com/tutorials/vertical-metrics

Not sure why the bold glyphs had thicker strokes when you made the changes. With rebuilds in FontForge, you will remove the hints that we use and should reapply those with the autohint.sh script in our postbuild_processing directory.

[chrissimpkins]

@Phantom-code Another good article:

https://grahamwideman.wikispaces.com/Font+Vertical+Metrics

[psycha0s]

@chrissimpkins thank you for the information. BTW, is it possible to build ttf files from sources on Linux platform? As far as I understood, the vfb2ufo tool exists only for Windows.

[chrissimpkins]

@Phantom-code The UFO source is always current with the latest release builds.

https://github.com/chrissimpkins/Hack/tree/master/source/ufo/vfb2ufo

You can build in FontForge with the UFO source files. We ran into some OT table build kinks with the attempt to transition to a UFO font editor but will be converting back to these as our working source in the near future. Of note, the ttf and otf builds themselves serve as their own source (though not all data in the source files is maintained). You can open either build type in FontForge, edit, and then rebuild the format that you want. The same caveat applies with the hinting anytime that you build new fonts. For ttf builds, use our auto hinting script and the associated Control Instruction Files in the directory that I linked above. For otf builds, we are currently using the FontLab Studio otf autohinter (and I believe that this may be the Adobe Font Development Kit autohinter which is F/LOS software). I’m not sure what autohinter FontForge uses, could be the same. The Adobe build tools are commonly used in font development.

Hope it helps.

[psycha0s]

Thanks again!

[chrissimpkins]

Started work on an application to address this. It will allow you to easily modify the spacing yourself. Hope to have a version that you can try in the next several days. Will post here when available.

[psycha0s]

Sounds awesome, I can't wait to try it.

[chrissimpkins]

If you are familiar with Python and want to collaborate on it, repo is here :

https://github.com/source-foundry/font-line

[chrissimpkins]

The initial release of the new line spacing adjustment tool is now available. Feel free to give it a try and please provide feedback on the tool repository if you encounter any issues.

More details in this new issue report: #191

[psycha0s]

Thanks, I will test it as soon as I can.

[chrissimpkins]

@Phantom-code no rush at all

[chrissimpkins]

Closing issue report now that the line spacing tool is available. We do not intend to modify the default line spacing at this point. Please reopen if you need and submit any issues with the tool on that repository.

[psycha0s]

Ok, I've finally packed font-line with its dependencies into Arch Linux packages and installed them. Now I will try to test it.

[chrissimpkins]

👍 Let me know what you think

[psycha0s]

I've run font-line percent 20 ./Hack-Regular.ttf and got the following error:

I've [font-line] ERROR: Unable to modify the line spacing in the font file './Hack-Regular.ttf'. [Errno 2] No such file or directory: '-linegap20./Hack-Regular'

Should I better report font-line issues in a different place?

[chrissimpkins]

yes let's move conversation about tool bugs there. try it with just the filename. I will modify the path parser. I think that is a problem on my end.

[chrissimpkins]

font-line fix released as v0.5.4. Pushed to PyPI. Thanks for reporting it!

[chrissimpkins]

Ok, I've finally packed font-line with its dependencies into Arch Linux packages and installed them. Now I will try to test it.

@Phantom-code : Did you make an Arch package for this or did I misunderstand this comment?

[psycha0s]

Yes, I did arch packages for commandlines, standardstreams and font-line, but I haven't public them. I'm not familiar with python packages and I didn't want to install all these files bypassing a package manager (pacman). So I created packages and installed them as usual. Maybe I could install them in my home directory somehow, but as I said - I don't have experience with python packages.

[chrissimpkins]

@Phantom-code any reason that you prefer not to install with pip?

[psycha0s]

The reason is my poor knowledge of subject (python packages) :-)

[chrissimpkins]

Line spacing shell scripts are now available and automate this within the range 10 - 30% UPM size (in 5 percentage point increments). Drop the script in a directory with only your Hack fonts and execute it.

They are available here:

https://github.com/chrissimpkins/Hack/tree/master/tools/line-spacing