Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bravura Text floods valid Unicode points with private characters #56

Open
lemzwerg opened this issue Nov 23, 2021 · 3 comments
Open

Bravura Text floods valid Unicode points with private characters #56

lemzwerg opened this issue Nov 23, 2021 · 3 comments
Assignees

Comments

@lemzwerg
Copy link

lemzwerg commented Nov 23, 2021

[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:

  • 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...

@dspreadbury dspreadbury self-assigned this Nov 23, 2021
@dspreadbury
Copy link
Collaborator

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.

@gpdf
Copy link

gpdf commented Sep 21, 2023

Any news on this?

@dspreadbury
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants