Underscore / underline interaction

[pikeas]

Breaking out from #234.

Just noticed some underline weirdness:

Is this the intended look of an underscore inside of an underlined section?

Reply from @chrissimpkins:

@pikeas I've never seen a render of the combination of an underscore and underline before, but you will want to be able to distinguish those things (i.e. you need to know that an underscore exists and that it isn't a space). Unclear why the renderer eliminates the underline below, but probably good that it does or it may appear as an emboldened line there. Suspect that underline only shows for you when glyph does not extend to within certain vertical metric. You can see this with the p glyph in that line as well. There is a gap in the underline at the spot where the p extends down to the underline.

[chrissimpkins]

Need this open any longer Aris? I don't believe that this is a bug. Is there a change that you are recommending in the fonts associated with this issue report?

[pikeas]

I opened the issue to ask whether this is the intended behavior. The rendering looks a bit funny, but I'm not sure that a double underline would be better.

If you're happy with the rendering as-is, feel free to close.

[chrissimpkins]

Do you have examples of other fonts and the way that this is handled with their renders? We run pretty tight line spacing and unfortunately, I am not sure that there is much that we will be able to do but I would be happy to look into it.

[pikeas]

I just reviewed several other fixed width fonts. Almost all of them render a double underline one way or the other.

Here's a double underline from M+ 1mn:

As an alternative, here's a raised thick underline from Menlo:

I'm not sure which option I prefer, this is definitely a case of "have you considered this edge case", not "I think it should be this way".

[chrissimpkins]

Thanks for the images. This is an interaction between the underscore glyph and the underline renders. Changes to the underscore glyph will have source code display consequences. This doesn't mean that we can't address this, but it will require some examination across source text to understand the effects of a change.

If you would like to see if you can find an approach that works for you with the underline positioning, you can try to modify the postscriptUnderlinePosition and postscriptUnderlineThickness values in the source, rebuild, and have a look on your platform. This is the only area in the UFO spec that I can identify for a change to underline renders. I don't know if your platform will pay attention to settings in the OpenType tables based upon those values or if it / the application is making decisions about how underlines render separate from the font settings.

These are located in XML files within each of the font variants on the path *.ufo/fontinfo.plist. Here are the keys for the two values for the regular set in the current master branch:

Hack/source/Hack-Regular.ufo/fontinfo.plist

Line 256 in 54bc87a

<key>postscriptUnderlinePosition</key>

Hack/source/Hack-Regular.ufo/fontinfo.plist

Line 258 in 54bc87a

<key>postscriptUnderlineThickness</key>

The same keys are present in each of the other three variant source directories. You can build new fonts with the instructions in https://github.com/source-foundry/Hack/blob/master/docs/BUILD.md

Post some screenshots of what you come up with if this leads to a better render for you. We can leave this open for further discussion once we see what you propose as a change.

[pikeas]

Modifying postscriptUnderlinePosition doesn't seem to change the rendering at all.

I really like the look with thickness bumped up around 120, it helps with the underline issue a bit, and also feels more balanced generally.

[chrissimpkins]

mind posting a photo of it?