This PR includes a new font, norns.ttf, which replaces the default 04B_03__.TTF.
What's new
Includes existing glyphs from 04B_03 with three changes:
Redesigned ♭ glyph to sit on baseline rather than extending 1 pixel below. Original glyph is available at U+E260.
Adjusted ~ glyph to be at a similar position as other operators (-+=). Original is available at U+0303.
Redesigned ø glyph to be distinct from Ø. Original glyph is available at U+00D8.
Adds 86 additional glyphs:
5 typographical including 3 space widths
10 media playback controls
14 roman numerals (1-7, for chords)
2 musical, full-size
5 ui
5 arrows
2 math
7 musical, superscript/superior
10 superscript numbers
28 superscript letters, a-z lower (& M for chords)
Why a font/why a new name?
The reasoning behind adding so many text glyphs, rather than expanding lib/ui is that these have the advantage of being usable in script preview text, menus, param names, etc...
The new name is intended to distinguish the font from the original, considering 1.) it now has more than double the original glyphs of the original (up from 99 to 238) and 2.) flexibility is needed to modify the font without misattributing changes or additions to the original designer. I reached out to 04B_03's creator, Yuji Oshimoto, and was granted express permission to create a new font based on the original typeface for this purpose.
Risks/issues
I've workshopped the font around the Norns Study Group and the feedback has been positive, but there are some risks to be aware of.
Even though care has been taken to change existing glyphs only where necessary- and those changes are quite minor- scripts will be affected. I've made sure that the previous glyphs are still available at new code points, so I hope script authors can implement a quick fix if needed.
Unicode does not have code points for musical superscripts. My approach to this has been to use the code points from a Private Use Area block used by the Standard Music Font Layout (SMuFL) specification, specifically Chord symbols and Standard accidentals (12-EDO).
Where we deviate from the SMuFL spec is that we are using those code points explicitly for superscripts, not full-size glyphs. The spec assumes a more modern font format like OpenType which can embed stylistic alternatives for individual glyphs.
Since we're working with TrueType in a constrained application, I think this is the best compromise. To wit, the full-sized versions of these glyphs already have dedicated unicode code points and this way we are using the closest thing to a standard that exists in this format.
Creating the .ttf binary is a bit more complicated as I've found some tools like PixelForge don't support 4-byte code points so some remapping and metadata cleanup is required using a different tool such as Typelight. Nothing too onerous and I'm happy to facilitate, but I've created a repo with instructions and source files for future maintainers just in case.
This PR includes a new font,
norns.ttf, which replaces the default04B_03__.TTF.What's new
Includes existing glyphs from 04B_03 with three changes:
Adds 86 additional glyphs:
Why a font/why a new name?
The reasoning behind adding so many text glyphs, rather than expanding
lib/uiis that these have the advantage of being usable in script preview text, menus, param names, etc...The new name is intended to distinguish the font from the original, considering 1.) it now has more than double the original glyphs of the original (up from 99 to 238) and 2.) flexibility is needed to modify the font without misattributing changes or additions to the original designer. I reached out to 04B_03's creator, Yuji Oshimoto, and was granted express permission to create a new font based on the original typeface for this purpose.
Risks/issues
I've workshopped the font around the Norns Study Group and the feedback has been positive, but there are some risks to be aware of.
Even though care has been taken to change existing glyphs only where necessary- and those changes are quite minor- scripts will be affected. I've made sure that the previous glyphs are still available at new code points, so I hope script authors can implement a quick fix if needed.
Unicode does not have code points for musical superscripts. My approach to this has been to use the code points from a Private Use Area block used by the Standard Music Font Layout (SMuFL) specification, specifically Chord symbols and Standard accidentals (12-EDO).
Where we deviate from the SMuFL spec is that we are using those code points explicitly for superscripts, not full-size glyphs. The spec assumes a more modern font format like OpenType which can embed stylistic alternatives for individual glyphs.
Since we're working with TrueType in a constrained application, I think this is the best compromise. To wit, the full-sized versions of these glyphs already have dedicated unicode code points and this way we are using the closest thing to a standard that exists in this format.
Creating the .ttf binary is a bit more complicated as I've found some tools like PixelForge don't support 4-byte code points so some remapping and metadata cleanup is required using a different tool such as Typelight. Nothing too onerous and I'm happy to facilitate, but I've created a repo with instructions and source files for future maintainers just in case.
Additional details available in attached pdf