period, comma, colon, semicolon misaligned; colon and semicolon slanted in italics

[madig]

I noticed that period and colon don't line up:

It's less noticeable for comma and semicolon. Looking through the UFOs, I found that additionally, colon and semicolon are slanted while period and comma aren't. A related issue #186 seems to have been closed?

[chrissimpkins]

Thanks for the feedback Nikolaus!

Re: period vs. colon vertical alignments in regular set:

There is no intent to meet standard type design guidelines in these fonts. In fact, we very intentionally attempt to question and break the rules that seem to be defined based upon body text where appropriate. I read Bringhurst and a number of type design texts as I was working on the early design changes to BVSM and then threw out the "rule book" and looked at every glyph in the Basic Latin regular set through a source code lens. One of the issues that we've attempted to address is the improvement of the semantic interpretation of the individual and grouped glyph idioms that are used in source code statements (and that differ from semantics used in body text). For instance, we've designed some semibold punctuation glyphs in the regular set. See the exclamation point as one such example. For this glyph, it is because NOT X is an important distinction to make from X in source code and !X is a broadly used idiom in programming language grammars. Use in source differs from written Latin languages where, in most cases, the exclamation point is used at the end of a sentence and has very different semantics where, arguably, identification of the semantics associated with the exclamation point is far less "important" (unless you are one who is really concerned about the level of excitement in a narrative...). From a cognitive standpoint wide stroked exclamation points would feel very out of place in body text. We can leverage that dissonance for effect in type. Many monospaced faces display an anemic exclamation point at text sizes used for source code editing because the glyph is commonly designed at the vertical stroke width of the rest of the regular set. I assume that this is a type design convention? My feeling was that it needed to be more apparent. There are many other design changes that were prompted by a review of the glyphs in bodies of source and intended to achieve dissonance during reading. I think that you are landing on one of those here. At some stage, it was felt that we needed to have distinct representations of these glyphs so that they drive some dissonance during reading. Having said that, there is no standard to follow about how these issues are approached and many of these design changes were based on experimentation and instincts. They are very open to debate and future changes.

I love how you are thinking here and really like to explore and address these issues. Rather than pitch a typographic convention, can you see a way to improve legibility/readability/semantics of source code text with changes in these glyphs? That would be the basis upon which we would conduct work. One might argue that the fact that you noticed the relationship between glyphs as "different" from your expectations may indicate that the way you process source code during reading with text laid out in Hack differs from the way that it occurs when you read source code laid out in a face that is designed for body text. The root question is whether that is desirable in this case and any other that you come across.

Re: differences in slants used for punctuation glyphs that you mentioned in italic sets

I honestly don't recall any basis for this. These may have been upstream designs that were not modified. Oblique is used in many syntax highlighters, but short of comment strings, I can't think of one that slants these punctuation glyphs. We can definitely optimize these glyphs for comment blocks and for body text use cases where users would like to lay text out in oblique. Do you have thoughts on whether it would be most appropriate to convert the slanted glyphs in the Italic set to non-slanted or non-slanted to slanted?

[chrissimpkins]

btw, it looks like you are using v3.003 (current release version) in the image above. There have been a number of changes in the Basic Latin set in the work that will be part of the v4.000 release. You can grab builds of the pre-release and not quite complete yet v4.000 fonts in #427

[chrissimpkins]

Lastly, I'll add that this is the body of sources that we use for our exploration/experimentation:

https://github.com/source-foundry/code-corpora

Search with Sourcegraph works very well to identify use scenarios for any glyph of interest. For ::

https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/source-foundry/code-corpora%24+%22:%22

[madig]

Ok, I can see why the punctuation is different, thanks for the explanation. I actually noticed because the intentional misalignment messes with hinting 😀 Compare the softness of the period vs. the colon. It's less apparent with comma and semicolon. Since I have all my TTFs on FreeType's slight autohinter (and everyone who uses Ubuntu and possibly derivatives vanilla), there is little one can do except align the thingies (maybe not exactly). Tricky. One way to get more control would be to make OTFs and define additional blue zones for psautohint.

Do you have thoughts on whether it would be most appropriate to convert the slanted glyphs in the Italic set to non-slanted or non-slanted to slanted?

Hm, I'd have to do some research on that actually. I only noticed because I looked at the UFOs, so maybe it's not as big of a deal...

[chrissimpkins]

Good technical argument for making changes if these are not rendering well on some platforms. I haven't noticed issues on Ubuntu / Arch or Win. Will definitely take a look. What sizes in the 8-14 range does this affect for you?

[madig]

VSCode says 14px.

I had a look at Consolas by the way, it slants punctuation in its italics.

[chrissimpkins]

Thank you! Will investigate.