Accidentals problem in Write Mode with November 2-Font

Dorico
#1

Is it just me or do other users encounter the same problem:

After having switched the music font from “Bravura” to “November 2.1” (correctly installed, mind you) the “Accidentals panel” in “Write Mode” is missing the glyphs for those six quarter tone-accidentals:

  • the triple flat
  • the five quarter-tones flat
  • the three quarter-tones flat
  • the quarter-tones sharp
  • five quarter-tones sharp
  • the triple sharp

(cf. my screenshots)

But not only are those glyphs missing in the UI, they also won’t get displayed in the score, when applied to a note - only a rectangular stand-in shape will appear in front of the selected notehead.

Hence my question: is this a bug? Or is this related to the font November 2.0?

2017-08-17th-November-&-Accidentals-forum-post-(MJ).jpg
2017-08-17th-November-&-Accidentals-forum-post-(MJ).jpg1701×858 106 KB

#2

I believe SMUFL’s structure changed slightly, and Robert might not have had the time to adjust November yet. There were some kins even with Bravura, if I recall correctly.

#3

Ah, ok. Interesting. Thanks for your take on this issue!

#4

I took a quick glance at the font and those glyphs may be missing (which would explain the problem in both the UI and in the score), but I didn’t time to look thoroughly. I’m certain the triple flat and triple sharp aren’t there, so I suspect the others are in the same boat, but I’ll confirm that shortly.

#5

Had a closer look. They are, indeed, missing from the font itself. Dorico’s off the hook this time.

On a side note, Daniel, why does the UI change with the music font? I can kind of see why it does (possibly for situations like this so you know what the font is missing), but to me it would be nicer to have the UI remain stable by always using Bravura while the score used the chosen music font. My two cents.

#6

Many of the panels are drawn dynamically using the same processors that are used to draw the music in the score itself. It would add quite a bit of complexity if we had to start carting around multiple sets of styles for each project just so we could draw with a different font, and I think in general it would actually be harmful rather than helpful anyway – not only in situations like this where a font is missing a glyph that the program relies upon, but also in case the font designer does something more unorthodox and makes the look of a glyph so substantially different to Bravura that the user would get a big surprise when creating that item.

#7

Hmmm… I guess I can only speak for myself, but I’d rather a consistent UI appearance showing Bravura glyphs on all the buttons, than have it dynamically update with whatever the main music font is, especially if the font designer goes wild and creates a substantially unorthodox design. I would much rather see a “normal” design because that’s what I’m used to seeing. In all fairness, I think most if not all music fonts will look “normal” enough that the symbol is clearly recognizable if used in the UI. I know mine are, but I still would rather a consistent appearance.

As a comparison, I can’t imagine using a word processor where the UI changed appearance depending on the main text font. That’d drive me absolutely crazy, but maybe others find it useful in this case. If it’s too complex to just use Bravura in the UI, then it’s too complex. I don’t think there’s really an argument, though, for needing to show the music font’s specific glyphs since they are SMuFL-encoded.

Sorry. It’s getting more OT now and I don’t mean to argue, just expressing my observations and personal tastes. Thanks for all you and the team do!

#8

Hi Marco Polo!

Sorry for the inconvenience, and I will make sure this is fixed in the next maintenance update of November 2!
(I will look at the other panels, too…)

Robert

#9

Awesome! THanks!