I am planning to build a web application that will use the Bravura Text font to display the results of musical calculations as staff notation (using the combining staff position characters). Initial experiments are inconclusive regarding wide browser support of Bravura Text. Some of them are displaying Bravura Text as if it were just the Bravura font.

Should I expect any browser that supports OTF to do the right thing with the combining staff position characters?

Is it only the OTF version of the font that implements the combining staff position characters, or should the WOFF versions do it too?

https://forums.steinberg.net/t/use-opentype-truetype-variant-of-bravura-to-boost-dorico-ui-responsiveness/696433

Embedded OpenType (EOT) is a format developed by Microsoft for the embedding of OpenType fonts in Internet Explorer. It is not supported by any other browser, including Microsoft's successor to Internet Explorer, Edge. See here for current browser support.

It's increasingly awkward to continue to produce EOT versions of Bravura, and since this format is basically entirely deprecated now due to the only browser in which it was ever used now being discontinued, I believe it would be acceptable to no longer deliver Bravura in this format.

If anybody in the community knows otherwise, please shout!

It should be PS-named BravuraText but in fact it's named Bravura Text which causes misparsing of the name according to many programs as PS names should not contain a space.

On https://github.com/steinbergmedia/bravura/releases, the latest release shown is 1.18.

This is two years older than the latest release in https://github.com/steinbergmedia/bravura/tree/master/releases (bravura-1.211.zip).

Please tag the latest release on GitHub; I was about to file a bug that's already been fixed :-)

Hi!

While all the ASCII characters are left unimplemented in the font, which is quite nice, it appears the "=" sign isn't, and, worse, it is implemented as a blank space. Is there a reason behind it?

Cheers,
Simon

The last git tag seems to be 1.271. On the website it says 1.276 is the latest. I just noticed the actual OTF font files claim to be 1.320 now!

Can we please git some new git tags for the releases up to the present so that distro packages can update without having to manually sort through commits?

I'd like to use this in a piece of open source software I'm developing and I'd like to make a webfont of it via FontSquirrel.

Is there a license that permits or bans this usage?

When I try to install the Bravura Font using Packages on an early 2015 MacBook Air running OS Catalina (10.15.7), I get the following message: 'The document “Bravura Font Family.pkgproj” could not be opened. The data is not in the correct format.'

👋🏽 I noticed that the stemUpNW and stemDownSW aren't symmetrical for flag glyphs, e.g. flag8thUp and flag8thDown (from bravura_metadata.json):

{
  "glyphsWithAnchors": {
    "flag8thUp": {
      "stemUpNW": [0.0, -0.04]
    },
    "flag8thDown": {
      "stemDownSW": [0.0, 0.132]
    }
  }
}

I was expecting these 2 anchors to be symmetrical across the y-axis at the origin, e.g. something like -0.04 and 0.04 for flag8thUp and flag8thDown respectively. The end result is that right now in my notation rendering engine, up flags and down flags are positioned asymmetrically too:

Stem up	Stem down

(Take a look at the point of the flag at the center line of the staff for each variation)

But I feel like I must be doing something wrong here 🤔 – is it expected that these 2 anchors aren't symmetrical?

We've noticed that many Sagittals have an advance-width of 187 when it should be 188. We've corrected that here.

Please copy the outlines and widths for all Sagittals (U+E300 to U+E40B) from this file. This will solve issue #52 as well as this one.

Thanks again and let me know if you have any questions.

Look at that. Notice that weird little imperfection?

Now, that's much better.

I've attached a ZIP of the fixed version (as an EPS). I claim absolutely no copyright on it, since I really have not done any original contribution, but I can say whatever you'd like, just as long as you fix the symbol!
uniE566_Bravura.zip

I asked @fkretlow for some feedback on the figured bass range in Bravura, since he's done a load of work on the Figurato font.

I’ve taken a look at the figured bass range. I think it’s complete from a semantical point of view. Whether there are any glyph variants that should be added is a more difficult question.

I’ve regularly seen the ligatures 2+, 5+ (also 4+) in published engravings, but you could argue that these are just crude renderings of figbass2Raised etc. The only one I’m really missing is the equivalent of figbass6Raised2 for 9 (the ligature 9' in Figurato). Also, you can sometimes see a variant of the double sharp that looks more like a normal x, but I haven’t even added that one to Figurato.

Since figured bass indications are usually set quite small, I think some of the modified numbers could do with a bit of tweaking to increase legibility, in particular figbass2Raised, ...4Raised and ...5Raised. Also, figbass6Raised2 (and the equivalent for 9) doesn’t usually have a ball terminal.

The glyphs for a simple hyphen (-, Ascii 0x2D) and equals (=, Ascii 0x3D) are missing in BravuraText. They seem fine in Bravura itself. (July 2019)

As of Bravura v1.271:

With the addition of condensed, sans serif time signature glyphs in the range U+F4EE - U+F505 and the condensed "normal" time signature glyphs in the range U+F506 - U+F52A, the glyph codepoints for all glyphs after that no longer match what's found in the metadata file.

For example, the glyph "fClef5Below" shows up at codepoint at U+F52B, but the metadata says it's at U+F4EE, which is where it used to be. The last glyph affected by this is "timeSig12over8" which is now found at U+F5F3, but the metadata file says is should be at U+F5B6 (where it used to be).

According to the changelog there seems to have been a 1.360 release, but there is no git tag yet. (See comments in #22 for why this is important.)

wiggleArpeggiatoUpArrow is not correctly tesselated with wiggleArpeggiatoUp:

The newer stem glyphs for headless notes (uniE204 and uniE205) have a retracted stem of about 50 units compared to the base glyph in the Stems range (uniE210), which extends to the baseline, as expected. The dimensions of the newer glyphs are not reflected in the source font, (Bach 4.1), and there does not seem to be anything in the SMuFL standard which might explain the choice. Is this an inconsistency or a conscious decision, and if the latter, shouldn't it be reflected in the standard?

@dspreadbury — sorry about this, but we've noticed that in the 1.392 release of Bravura, some subtle issues with Sagittal glyphs that we had corrected on our end and submitted to you in December 2020 to be included in that release are unfortunately still there.

Here's the GitHub issue comment where I submitted our corrected font from which to source the glyphs, and explained the two issues (directions, and extrema): #39 (comment)

Looking back on it, I can see that I probably failed to make myself clear that I was providing you a new font, and not simply providing additional color on what I had already submitted.

For convenience, here's that font again here. So if it's possible — since v1.4 is still not out yet — would you be able to source our new glyphs from:
BravuraSagittalUpdate_v11.zip

And again, the glyphs are in the ranges U+E3F4 – U+E3F7 (Olympians) and U+E3F8 – U+U40B (Magratheans).

Thanks as always for your assistance. And let me know if you need anything else from me.

Hello,

we are unable to have correctly rendered chromatic solfege on a staff if we use accidentals in given key. Also for Minor keys the current solfege noteheads are not complete. I can not for example "visually" sing Minor3rd.

“do, di, re, ri, mi, fa, fi, so(l), si, la, li, ti, (do)” and “do, ti, te, la, le so(l), se, fa, mi, me, re, ra (do)"

Thank you, Marek.

Some of the glyphs in the unicode block U+1D100 - U+1D1DD appear to have incorrect glyphs. While I am not even close to being an expert in mensural glyphs, as far as I can tell, the following code points need to be fixed (maybe others, too):

• U+1D1BC (MUSICAL SYMBOL MINIMA BLACK)
• U+1D1BF (MUSICAL SYMBOL FUSA WHITE)
• U+1D1C0 (MUSICAL SYMBOL FUSA BLACK)

Data for set "ss09" (Time Signature, Large Narrow) is completely missing from the metadata file.

I'm using JSDelivr to get the files from this repository.

In this repl.it project, the glyphs in the "Time Signature" section's combo boxes are supposed to be raised to the numerator position. But:

1. Multiple characters overlap (the 1 and 2 in 12 are overlapped, similar for 16)
2. The characters do not move, even though there is a timeSigCombNumerator

0049 0074 0020 0069 0073 0020 0068 0061 0072 0064 0020 0074 006F 0020 0072 0065 0061 0064 0020 0068 0065 0078 0020 0063 006F 0064 0065 0020 0070 006F 0069 006E 0074 0073 002E

Some might be able to read the above, because it is ASCII, and ASCII has been around for a while. But while editing or viewing HTML/SVG files containing Bravura font codes, it either looks like the above, or like the following:

While both are decipherable, neither is friendly and readable.

BravuraText? Well, it has its place, but isn't intended for displaying characters separately, but rather in groups, so a sequence of Bravura characters is likely to produce some unintended display consequences.

Bravura itself? Well, even more so than Bravura Text, it is variable width (which a fair number of text editors can't handle), and when the text is embedded in other code and text, doesn't have all the other Unicode glyphs.

Suggest a BravuraMono for text editing purposes... for editing source files containing Bravura symbols, as long as the editor can do font substitutions so that multiple monospaced fonts can be examined for finding the characters. One could put BravuraMono first, and fall back to the collection of regular fonts, or put BravuraMono last. BravuraMono wouldn't need glyphs in the standard ASCII/Latin regions which are well covered by other fonts, but if it had some, then the order of searching would select from different fonts.

Yeah, it would be a lot of work for a limited purpose, but it sure would make examining the source or HTML or SVG files containing Bravura a lot easier. If a particular symbol can't be recognized because of its size and complexity, one can either zoom in, or ask the editor for the character code, or copy/paste to a different application. But most common characters are likely to be somewhat recognizable even at normal text sizes. The point here is to avoid the combining done by BravuraText and the odd sizes of some characters in Bravura, by reducing them to a monospaced representation of individual characters.

It appears that even though the Kievan symbols exist in the range U+EC30 - U+EC3E, they are missing from the corresponding unicode block codepoints U+1D1DE - U+1D1E8.

Thanks for the 1.35 tag, but we have a new problem! This version number is smaller than 1.271 (the last official tag) and also smaller than 1.320 (the last unofficial release I fudged an Arch Linux package for by patching in a tag).

I know in the font likely says 1.350 internally since three digit numbers are traditional (SIL & OpenFV recommendations) but the git tag needs to reflect that as well so that package managers understand that 1.350 is newer than 1.271.

The whole-rest glyph has the metrics set so that it hangs from the third line on the staff. This is incorrect according to Wikipedia https://en.wikipedia.org/wiki/Rest_(music). It should hang from the second line on the staff.

This is in Bravura (as opposed to Bravura Text).

Note that the long, breve, and minim rests are correctly positioned (center two spaces, second space, and resting on the third line respectively) so I know that my rendering is set up correctly in general.

This was noted in a forum post in 2015 (https://forum.makemusic.com/default.aspx?f=6&m=453271) saying "the default position of the whole note rest is lower than Finale expects".

I recently picked up an old personal project and updated BravuraText.otf from v1.271 to v1.390. After doing so, the methods I used to generate key signatures no longer functioned properly. The signature for F major, incidentally, would only appear for the treble clef, and the signature for E major would only appear for the bass clef, but all the accidentals collapsed to a single column.

The differences in the ligature lookup tables between v1.271 and v1.350+ indicate that some refactoring occurred in the assembly of the ligatures. Taking a sharp (u+E262) raised one position (u+EB90), for instance, a direct comparison between the old EB90_E262 (at 1119618) and the new u+10B7B (at 68475) shows that the newer ligature glyph has a width of 0 and a right side bearing of -199. I haven't made an exhaustive search, but this seems to be the case for many of the glyphs that employ staff position ligatures: the width became 0 and the right side bearing became the negative of the old width.

This must be the reason for the erratic behavior I described above. I can even use a string such as "\uEB90\uE262 " to see a sharp raised one position and cut in half. Of course, this proves a workaround of using the '-' spacing character to fill in the width of the ligature, but that means I would have to keep track and not add extra space after characters that should be in the natural position in the middle of the staff.

I'm trying to print time signatures using glyph tables but it doesn't work because it doesn't recognize the symbol.
Example: uniE09E_uniE087_uniE09F_uniE088 is not recognized, while if I use just uniE087 it works perfectly

What's up with that corner? 8th, 16th, 32nd, displayed in order. 8th is also different but this may be intentional. I just don't get the corner.

Writes @cmloegcmluin:

We have removed the right side-bearings from two Sagittal glyphs:

• U+E3F0, accSagittalShaftUp
• U+E3F1, accSagittalShaftDown

because they are not diacritics, and need to be consistent with the Sagittal accidentals. We have left the right side-bearing on the actual diacritics, including the new ones, so that kerning works correctly.

Writes @cmloegcmluin:

I remind you about the new kerning pairs associated with the new diacritics added in the SMuFL update.

We figure the simplest way for you to transfer these changes to Bravura is to simply copy all the glyphs and all the kerning pairs in all Sagittal ranges, as well as the other 5 codepoints listed in #41, from BravuraSagittalUpdate_v10 to Bravura.

The Time signature fraction slash glyph (uniE08E) in Bravura is scaled according to the size of the fraction numbers (≈50%) rather than the time signature numerals themselves.

Since there are no encoded fraction numerals at 50% size, and since the numerals in the fraction glyphs are simply scaled down versions of the regular numerals, I think the fraction slash glyph should logically be set at the same size as the numeral glyphs (and all the other glyphs in that section for that matter.

Hi,

I'm considering developing an application for editing music notation and was interested in using the Bravura font for this. I'm having trouble finding clear instructions on how to go about installing and using this font both for Windows 10 and for the web. It'd be nice if this info were in the primary README file this project. Please advise - Thanks :)

There is almost no browser support for SVG fonts any longer, per this page and this discussion, so I plan to stop producing an SVG version of Bravura and Bravura Text with immediate effect.

There used to be several hundreds fingering code points in both SMuFL and Bravura. I wonder if there's any plan to release a font with just these symbols?

So writes @cmloegcmluin:

The Sagittal glyphs were originally designed by Dave as TrueType outlines at 2048 fu per em. When they were converted to Postscript Type 1 outlines for Bravura at 1000 fu per em, many visible artifacts were introduced by the rounding, such as triple-shaft symbols having unevenly spaced shafts, symbols not correctly vertically-aligned on the staff, and up and down versions of the same symbol not being mirror images. There are also 5 non-Sagittal glyphs in Bravura that were designed by Dave, that have the same problem. These are:

• U+E284, accidentalNarrowReversedFlat
• U+E285, accidentalNarrowReversedFlatAndFlat
• U+E47B, accidentalWilsonPlus
• U+E47C, accidentalWilsonMinus
• U+E47D, accidentalLargeDoubleSharp

I developed a FontForge script that repaired the damage and allows these glyphs to render correctly at 1000 fu per em.

In the latest version of Bravura.svg the <metadata>, @font-family, and all the @glyph-name disappeared. Is this intentional, and if yes, why?
Could it be brought back?

As of Bravura 1.32, there are two problems with wiggleGlissando:

1. It does not stand on the baseline but almost one staff space above it

2. The right side bearing is off, so tessellation is not correct when drawing a string of multiple glissando marks

(On a side note, to me it is annoying that the wiggle glyphs stand on the baseline rather than being centered around it, but that could of course be a matter of taste, programming-wise)

When I try to install, Norton constantly detects InstallBravura-1.204.exe as a virus.
Somehow, I installed it. But I see some character's permission as private use.
This is the screenshot of it.
https://www.screencast.com/t/DHM2SAtEI

In use, it seems to have the same bounding box as the ornamentMordent, but it's missing from the metadata file.

All stylistic alternates and ligatures in Bravura are named as unique characters, while SMuFL references their primary character(s).

E.g., the character flag8thUpStraight is named uniF40F in Bravura, while SMuFL appropriately names it uniE240.salt01, since it's primary is uniE240 (flag8thUp).

Similarly, accidentalFlatParens is named uniF5E0 in Bravura, contrary to uniE26A_uniE260_uniE26B in SMuFL, referencing all it's component parts.

I'm not totally clear on how this applies to the AGLFN recommendations, but SMuFL's naming scheme is at least what I personally would expect to see, and it's even entirely necessary for any scripting involving these glyphs to be universal, all the while SMuFl does not specify codepoints in the U+F400–U+F8FF range.

Especially since it seems that some font creators take their cues about naming from Bravura rather than SMuFL, I would suggest that future versions of the font adopt the naming suggested in SMuFL for all alternates and ligatures.

Hi!

I'm trying to load the BravuraText.woff2 by using css @font-face rule, but I'm getting the cmap error in chrome and firefox. Is this a known limitation?

test case:
https://jsfiddle.net/xda128b7/3/

w10/chrome( 83.0.4103.116（Official Build）):

Failed to decode downloaded font: https://raw.githubusercontent.com/steinbergmedia/bravura/master/redist/woff/BravuraText.woff2
?editor_console=:1
OTS parsing error: cmap: Failed to parse table

w10/firefox(78.0.1):

downloadable font: cmap: Final segment start and end must be 0xFFFF (0xF52B-0xFFFF) (font-family: "BravuraText" style:normal weight:400 stretch:100 src index:0) source: https://raw.githubusercontent.com/steinbergmedia/bravura/master/redist/woff/BravuraText.woff2

downloadable font: cmap: Failed to parse format 4 cmap subtable 0 (font-family: "BravuraText" style:normal weight:400 stretch:100 src index:0) source: https://raw.githubusercontent.com/steinbergmedia/bravura/master/redist/woff/BravuraText.woff2

downloadable font: cmap: Failed to parse table (font-family: "BravuraText" style:normal weight:400 stretch:100 src index:0) source: https://raw.githubusercontent.com/steinbergmedia/bravura/master/redist/woff/BravuraText.woff2

downloadable font: rejected by sanitizer (font-family: "BravuraText" style:normal weight:400 stretch:100 src index:0) source: https://raw.githubusercontent.com/steinbergmedia/bravura/master/redist/woff/BravuraText.woff2

osx/safari 13.1.1(13609.2.9.1.3);
BravuraText.woff2 is loaded with no error.

Best Regard,

Hello,

All named noteheads ( solfege, abcd ) are a bit bigger than normal noteheads. Which causing issue when rendering on a staff. I understand that we have bounding boxes in metadata but generally I feel the named noteheads should be the same size as normal noteheads so that we can use them on staves. Now it requires quite a bit extra work to scale all named noteheads down so that they much stave line height and certainly are correctly aligned with stems and in chorded groups.

Thank you, Marek.

I am seeing an advance width for musicalsymbolornamentstroke4 (U+1D19E), glyph 3258 in Bravura Text v1.277 of 65536 ... maybe intended to be -1?

Per w3c/smufl#156 we now need to add these new glyphs to Bravura. Douglas Blumeyer (@cmloegcmluin) has provided a version of the Bravura OTF file with the new accidentals added. These need to be merged into the master version of the font.

I am new to smufl, so I might be missing something.

The default notes (like U+E1D2) seem to have width attached to them. However, when combined with vertical-position shifting symbol, they have zero width (like U+EB98 + U+E1D2). This seems to be more-less what #31 complains about.

However, even if I accept the inconsistency and decide to compensate for it by adding spacing manually (which is still not ideal, since it limits how symbols can be combined). The default note width is slightly smaller than the width of = - please see the attached picture for sample rendering.

Is this problem in my understanding of how the font is supposed to be used or is this actually problem with the font?