New music notation font

• Jul 15, 2013 - 09:45

Hi everyone,

I have been making a new music notation font. Parnassus is a haskell program I am making for
experimenting with music layout, but there hasn't been much progress. But I have a useable font,
and Nicolas has helped me porting it to MuseScore. It's not complete, but it has all the basic glyphs.
You can read more about it on my website: http://www.resonata.be/archives/117

Regards,
Kristof Bastiaensen

Comments

• Nov 28, 2018 - 23:31

Ooooh, I really like the accidentals in the Parnassus drafts/examples, they're not as hole-y/open and with more defined strokes.

I don't quite like the bleeding, though... guess I'll stick to MScore (Emmentaler) for now, I've been looking at musical fonts tonight and, given that even creators of alternatives praise it, and it looks "larger", not as filligrane, making it easier to read during a performance, really helps (though I never liked its natural accidental at all).

Reply

• Oct 21, 2020 - 00:54

Meh. Some scaling needed.

Screenshot_20201021_014746.png

While I like the new ♯ already, the ♭ is rather weak. (And I need a ♮ for comparison, because that one utterly sucks in Emmentaler.) I suspect Parnassus is pre-SMuFL. I really need to understand its bbox values in the provided XML file… but probably just do size comparisons to noteheads and scale things to match SMuFL.

Incidentally, parnassus-mscore.sfd is provided under the correct licence to merge individual glyphs over ☻ (GPL with font exception, same as Emmentaler/MScore).

Reply

• Oct 21, 2020 - 07:29

Why merge Parnassus into Emmentaler rather than having it as a separate font?
BTW: A new font, Leland, is currently being designed/developed for MuseScore, by a staff member, AFAIK it is planned for MuseScore 3.6, and is planned to be come the new default for MuseScore 4 (and part of its development builds already, in an early form)

Reply

• Oct 21, 2020 - 18:43

I actually like Emmentaler but hate its accidentals (and the 8vb clef bug). I don’t like the overall look of Parnassus, but its accidentals are much closer to the engraved music I collected over the years.

I saw the development of the new one (by Tantacrul on Twitter) but, as I said, I like Emmentaler per se.

Reply

• Oct 22, 2020 - 04:24

That’s what I wrote ☻

But I decided to split these and deal with the accidentals first.

My WIP is at https://github.com/mirabilos/MuseScore/commits/parnassus-accidentals in case someone wants to have a look at it (this branch may be subject to force pushes); I also had to fix a couple of other issues in the font (nōn-integral points, open paths, missing/outdated hinting information, etc) but learnt tons about fonts and SMuFL during it and had a blast ☺ (well as much as one can while ill in bed).

Reply

• Oct 22, 2020 - 05:38

OK, this is quite… well, the ♮ is a definite improvement (except for hinting of the rightmost vertical line at small sizes, like 100% view on my 91 dpi laptop in the software itself), the sharps are not much of a change (but go well), and the ♭… hmm… if sitting in a space it cuts the lower stave line somewhat fierce, but at a distance or smaller sizes it’s great. I think I’ll either increase the advance width of the accidental-opening-parenthesis a bit or move the ♭ so it begins at position 0, depending on how well MuseScore deals with the advance width (it seems to not honour it for the ♭+closing-parenthesis sequence… might be useful to investigate that instead or additionally).

MScore with Emmentaler accidentals:

accidentals-emmentaler-1.png

MScore with Parnassus accidentals, WIP:

accidentals-1.png

Check it from a slight distance. Zooming in you see more details than normally visible.

I think I also should investigate the differences between parnassus.sfd and parnassus-mscore.sfd regarding the ♭ vs. notehead size.

But, all in all, this is much closer to professionally typeset notation from the last century. (Looking at some real notation, the cutting the baseline is not a problem. I need to check the hinting and thickness of the vertical line in the ♭ as well. But this is only apparent on low-DPI devices.)

Screenshot_20201022_063629.png

Reply

• Oct 24, 2020 - 07:43

I’m reasonably happy with tonight’s WIP version (commit 4cd5fbefdeb324e2605043d86095b8f29142c755 in my branch). Screenshot:

Screenshot_20201024_082222.png

(It turned out kerning was ignored, but slightly adjusting the ♮ glyph helped.)

PNG export (full resolution):

accidentals-1.png

I’ve patched the accidentals renderer to honour the lower advance width of the ♭ accidental before the closing parenthesis.

The new font is also a native TrueType font (quadratic splines), not one dynamically auto-converted into TrueType by FontForge from cubic splines (PS font), which allowed me to optimise the splines quite a bit and make use of relocation (e.g. all the clef variants are now stored only once, and the ottava clefs just embed the normal glyph). This saved 25% (!) of the TTF size, and it can also reduce the size of the generated PDFs/SVGs/etc. (I’ve also removed over 12½ KB of redundant spaces at end of line from the font SMuFL JSON files… this all shaves off quite a bit from the binary size, too… we could save more by using tabs for indenting it, but I’ll leave that open for another discussion, while redundant whitespace at EOL can just be killed.)

And, of course, doing an almost-full review of the font, I found quite some places where glyph edges were… suboptimal or even just plain wrong (one even possibly triggered a renderer error, though not in MuseScore/Qt); for example in the treble clef:

Screenshot_20201024_083833.png

Needless to say, I’ve fixed those which either I or the automated testing tools of FontForge found.

Reply

• Oct 24, 2020 - 08:07

Nice to see another user experimenting with the fonts. The FontForge experience is interesting to say the least. Personally, I'd like to see in the future some more MuseScore users contribute to some alternative font formations/choices and have the 'open-source' attitude trickle even further with community font formation choices, kind of like with what is found the SoundFont (SF3/SF2) forum every now and again but for notation fonts :)

Reply

• Oct 24, 2020 - 21:04

Indeed, we shouldn’t (at least other than the one-time whitespace fix).

I saw you comment on https://github.com/musescore/MuseScore/pull/6742#issuecomment-715885497 and brought this to SMuFL.

Maybe for master we can build-depend on jq which can remove all optional whitespace from these files at build time. A Windows version of jq exists. Not sure whether an extra dependency will fly with people wanting to compile, though, which is why I’d suggest to leave this as-is for 3.x and consider that separately for master.

Reply

• Oct 24, 2020 - 22:41

Works for me. Something like cmake -E copy_files to copy the files from the source tree to the build directory for dev builds then, and a loop over all files converting them, like…

mkdir -p $objdir/fonts/bravura $objdir/fonts/gootville $objdir/fonts/mscore $objdir/fonts/musejazz $objdir/fonts/petaluma $objdir/fonts/smufl
for file in fonts//.json; do
jq -c <"$file" >"$objdir/$file"
done

(or srcdir-relative in objdir)… for release builds (and the equivalent batch magic for Windows).

Reply

• Nov 23, 2020 - 13:04

Looks good! I hope MuseScore supports installing external SMuFL fonts in the near future (and that the team is implementing the new Leland font already thinking on getting MuseScore ready for any SMuFL font)

Reply

Do you still have an unanswered question? Please log in first to post your question.