You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was quite shocked to see that 'Bravura Text' abuses valid Unicode points for its private set of glyphs! This is an absolute no-go. In particular, it simply continues assigning glyphs after the Private Use Area (U+E000–U+F8FF) with U+F900, U+F901, etc., in the cmaps instead of correctly using U+F0000–U+FFFFF (Supplementary Private Use Area-A) or U+100000–10FFFF (Supplementary Private Use Area-B).
Some bad examples:
U+106AE is 'LINEAR A SIGN A414-VAS'; 'Bravura Text' instead shows a whole note.
U+130AE is 'EGYPTIAN HIEROGLYPH D050A'; 'Bravura Text' instead shows a natural accidental.
Font management software like 'FontConfig' (on GNU/Linux and BSD) analyzes a font after installation to find out what Unicode glyph ranges are supported. Due to the wrong Unicode assignments, it would use 'Bravura Text' as a fallback font for all languages that are completely covered, for example Cuneiform (U+12000–U+123FF), Bhaiksuki (U+11C00–U+11C6F), and many others, causing severe Mojibake-like havoc.
Since all glyphs with those wrong Unicode points are never meant to be accessed directly by code point but by ligatures (according to bravura-text.mf), there is zero reason to not fix this, making 'Bravura Text' a valid font that can be universally used. In particular, I strongly suggest to exclusively use ligatures without assigning Unicode PUA values at all – software that understands Unicode values larger than U+FFFF should be able to properly handle ligatures...
The text was updated successfully, but these errors were encountered:
Thanks for reporting this, Werner. You're right that this is incorrect. We'll either fix this so that it correctly assigns codepoints in the next PUA range, or consider preventing it from assigning any codepoints at all. I don't know exactly when the next version of Bravura will be on its way, but we'll take care of this then.
I'm working on the next version of SMuFL at the moment, and one of the things that this will entail is changing the way that fonts for text-based applications works for the future, and in this proposed future we will no longer have all of these combinations for ligatures to produce symbols at different staff positions. However, we will maintain the current version of Bravura Text for a time to allow people to transition away from the old font, and we'll see about fixing this specific issue at that time. Sorry that I can't commit to fixing it more quickly.
[ver. 1.392]
I was quite shocked to see that 'Bravura Text' abuses valid Unicode points for its private set of glyphs! This is an absolute no-go. In particular, it simply continues assigning glyphs after the Private Use Area (U+E000–U+F8FF) with U+F900, U+F901, etc., in the cmaps instead of correctly using U+F0000–U+FFFFF (Supplementary Private Use Area-A) or U+100000–10FFFF (Supplementary Private Use Area-B).
Some bad examples:
Font management software like 'FontConfig' (on GNU/Linux and BSD) analyzes a font after installation to find out what Unicode glyph ranges are supported. Due to the wrong Unicode assignments, it would use 'Bravura Text' as a fallback font for all languages that are completely covered, for example Cuneiform (U+12000–U+123FF), Bhaiksuki (U+11C00–U+11C6F), and many others, causing severe Mojibake-like havoc.
Since all glyphs with those wrong Unicode points are never meant to be accessed directly by code point but by ligatures (according to
bravura-text.mf
), there is zero reason to not fix this, making 'Bravura Text' a valid font that can be universally used. In particular, I strongly suggest to exclusively use ligatures without assigning Unicode PUA values at all – software that understands Unicode values larger than U+FFFF should be able to properly handle ligatures...The text was updated successfully, but these errors were encountered: