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.) Aburarv.zip (709.1 KB) Aburarv Tekisuto.zip (1.2 MB) Akademikku.zip (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.
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.
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.
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.
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.