I am considering adding a variation axis to my font that controls the width of spaces. The reason is that Unicode contains a broad yet inconsistent set of space characters. They differ mainly in width and whether or not to prevent a line break. When wearing my typographer hat, I find the Unicode spaces-set quite limiting and frequently wish for a non-breaking space that was a bit narrower or a bit wider. All non-breaking spaces that the universal codespace offers are U+00A0 (word space width), U+202F (narrow), U+2007 (figure width), and U+2060 (zero width).
Use cases include:
- a comma after an en/em dash “[…] – […] – , […]”, where some want to insert a thin non-breaking space between the dash and the comma
- French quotation marks, where many strong opinions exist on exactly how wide the non-breaking space between quote and letter shall be
- other punctuation, e.g., a thin non-breaking space before the percentage “%” sign
- abbreviations such as “z. B.” where a non-breaking word space may appear a bit too wide, while U+202F is too narrow (I have seen prestige fonts that have a slightly narrow U+00A0 compared to the regular U+0020, probably to address abbreviations, but that is not a good solution)
- sentence spacing, where a single word space would be enlarged if set between two sentences (here again many strong opinions on how wide such a space shall be, in case the sentence space should differ at all from the word space)
So, my idea is to add a “Space width” variation axis (SPWD) with a range of 0–600 and a default of 100. 0 sets the width of space glyphs to zero, 600 multiplies the width by 6 (600% width). The axis would apply to all Unicode spaces so that the most semantically correct choice could still be made while allowing for the desired visual delimitation. The extra drawing work and file size increases are manageable.
I don’t want this to be a discussion about whether any of the listed use cases are valid – that is not for the type designer to decide – but whether a variation axis for space widths is technically/semantically sound and the proposed implementation is sensible.