Use OpenType-TrueType variant of Bravura to boost Dorico UI responsiveness

I currently have no 4k monitor to test the performance improvements with these OpenType-TrueType fonts, but even if I am using only a 144hz 1080p monitor I noticed significant responsiveness improvements happened after using these fonts.

(These font files are generated using TransType 4.)
(Looks like I don’t have to buy an M1 mac mini at this moment, saving my budgets for incoming Dorico 4, etc.)

Files for installing OpenType-TrueType fonts in parallel with vanilla official fonts.

(Using “Aburarv” “Aburarv Tekisuto” “Akademikku” as PostScript name for these OpenType-TrueType variants.) (709.1 KB) Aburarv (1.2 MB) (310.7 KB)
Currently, there is an issue that these alternatively named font files won’t show up in Dorico SMuFL font list.

Files for replacing existed Bravura / Bravura Text / Academico fonts. (283.1 KB) Bravura (1.2 MB) (709.2 KB)

Can you provide timings for this improved responsiveness (from the log files)?

What’s the data on Intel CPUs being slower at cubic curves?

Still, unless this cuts things by a large factor, I’m not convinced that it is a worthwhile procedure.

Also, (as I’ve said on the FaceBook post): Dorico uses OpenType features like stylistic alternates and advanced ligatures, which I’m not sure TrueType can handle.

Looks like OpenType-TrueType is really a confusing concept.
I uploaded renamed OT-TT files for those people who want their vanilla otf files being kept intact.

P.S.: I just asked a friend who works as a senior font programming engineer (he asked me to keep him anonymous in this thread), and he told me that OT-TT is much faster (comparing to OT-PostScript) and is beneficial for high-performance realizations, regardless that OT-TT (using only quadratic curves) theoretically requires more dots. Besides, PostScript embeds programming language, making itself much more sophisticated comparing to OpenType-TrueType.

Can you give us some numbers of the performance improvement you are seeing? (Using the times reported in the application log for each task.)

I’m skeptical that this is a limiting factor in screen display.

I will find some time to do this test in this week using this project:
(No VST instruments will be inserted during the test.)
ShikiSuen/engraving-gustav-op32_03: Reproducing the sheet music of Gustav Holst’s Op32-03, the “Mercury Symphony”. (

On a very quick test, I see no difference for scrolling and zooming, and between 1% and 3% faster for tasks like adding a Player to a large score. This on a 2560 x 1440 display.

Realistically, we’re looking at a fraction of a second improvement on even the longest tasks.

On top of that, you’ve got to remember to sort out font conflicts every time Dorico’s update installer puts the OTF Bravura back, and you’ve got to revise your TTF font when Bravura gets updated.

We can automate this process by using terminal scripts + AFDKO (using its otf2ttf function to auto-convert the fonts to OT-TT without modifying its SMuFL font features).

More work, more risk of something getting corrupted, for very little gain. Given that the team have said they plan to improve performance in future versions, I suspect that Dorico 4 will have speed improvements of a much greater size than this.

We shall see those possible improvements in Dorico 4.

By the way, I don’t recommend replacing original fonts anymore (to cope with fears like yours). I uploaded modified fonts with different PostScript names in order to let them being installed in parallel with Steinberg official PostScript fonts.

I’ve got a 3 Ghz 6-core i5 Mac Mini. Dorico is performing tasks in milliseconds.

The thing slowing it down the most is the guy in the chair!


I’m using i7-8700B with my mac mini. 32GB RAM installed. macOS Big Sur 11.2.1 update installed.

Gonna go for my supper now. Maybe I can do the test tonight.

To be fair, even minuscule improvements in performance are always welcome. As you said, the team is continually working on making it faster. I’d be interested to see the actual speed data from the application log, though I probably won’t take the time to do it myself.

1 Like

Before doing this test, I want to share my concern that the improvements may not be reflected too much on condensing. To calculate the condensing contents (before pushing the content to the screen), only the location-related and dimension-related data (such as height & width) of each glyph are required from the font file. The curve data is only used when rendering things to the screen and the printed files (incl. PDF, SVG, etc.)

Therefore, the improvements are likely to be happend with the UI responsiveness in these occasions (except contextual changes are triggered: 1) moving notes upside-down; 2) entering notes; 3) entering dynamics; 4) grouping dynamics… too many possibilities.

I downloaded your Mercury file, but Dorico cannot open it, reporting “Error opening file”.

Did you download through this page?: engraving-gustav-op32_03/Mercury - The Winged Messenger.dorico at master · ShikiSuen/engraving-gustav-op32_03 (

Yes, I went there. Click on “get file”, then right clock on file. Downloads 93.6k without problem. But doesnt load.

Weird. It loads successfully on my side.
Try this?
Mercury - The Winged Messenger.dorico (1.1 MB)

That works - a much larger file (1.2 MB)!

1 Like