Kerning a musical font

phatmatt's picture

I am in the midst of trying to put together my first "font" for notating a medieval style of musical notation called square note notation. My purpose is to be able to notate Gregorian Chant more accurately. The attached PDF gives an idea of how it looks. I am using FontForge.

This musical notation uses a four line staff. In order to facilitate input of glyphs, I am creating hundreds of liga/ccmp features. The number characters specify the height of the note, and when followed by a note type specifier character, they combine to create the notes at different heights. So far all of this has been a proof of concept, and in InDesign it works pretty well.

But I would like to make it usable in Microsoft Word. For the most part it works fine, but I can't get the kerning to work correctly in Word. Specifically, the vertical lines connecting the notes require kerning to move subsequent notes back up to line up to the note (see the notes over "ta-lem" for a specific example. In Word, I just can't get kerning to work, not by class, not manually. Yes, I've enabled kerning in Word itself, I've tried generating old style kerning tables, etc.

My question is this: is this probably something wrong with my font, or does Word not kern by glyph but by character? I've tried inserting the unicode glyph characters in directly, and still no kerning, but I'm just wondering if I'm missing something about Microsoft's kerning support...?

Thanks for any advice you might have... -phatmatt

Crux fidelis.pdf34.91 KB
Miss Tiffany's picture

Interesting project. I"ll move your thread to the BUILD area. You should get more response there.

Miguel Sousa's picture

Which font format are you using? TrueType? OpenType TT? OpenType CFF?
Also, beware that MS Word does not support 'liga'.

dezcom's picture

Why Word for this kind of thing?


phatmatt's picture
  • The format I was planning on using is OpenType TT.
  • Re: Word's support for 'liga', I am using Office 2007, and the 'liga' features are working fine actually, even with 3 character ligatures. Is it older versions that don't support 'liga's?
  • The only reason I want to support Word is to make the font as accessible as possible. I am not sure how many people interested in chant are going to be familiar with working in InDesign.
Miguel Sousa's picture

OpenType TT with old style kerning table should work fine in Word. Are you sure FontForge is generating a valid font?

If I remember correctly, Word 2003 (and earlier) don't support 'liga'. If your goal is to address as many Word users as possible, you can't assume that they're all using the latest version, or on the same platform (Word 2004 for Mac).

phatmatt's picture


Thanks for the clarification. I will run the font file against Microsoft's Font Validator and see if it needs to be cleaned up.

I'm pretty new at this stuff, but I thought I read that also mapping 'ccmp' features would make the font a little more widely available...? Word support for me is not an absolute requirement, but I didn't think it would be a kerning problem that's holding me up... :-P

Does kerning by class have any part of this equation, or should it work the same as setting kerning pairs manually?

Thanks, -M

Miguel Sousa's picture

I never used FontForge, so I don't know how kerning is done there. In FontLab you can do your kerning using classes, but that doesn't mean that's how it will end inside the font file, since FL allows you to expand the kerning and/or implement the kerning in the font via the kern table instead of the kern feature (in the GPOS table).

elena's picture

I'm really astonished to see that someone else is working on this topic. I just published an OpenType font for the neumatic notation, Gregoria, in collaboration with a french Abbey.
It doesn’t really work with MS Word because it extensively uses contextual alternates (and ligatures of course). I think it’s very difficult to make it work with Word because no standards have been defined for this notation. But as we were also concerned by a wider accessibility than InDesign users, the Abbey is working on a free software to distribute together with the font (Gregorio), which will provide an easier user interface; it’s almost finished.
Are you also interested to make it work on musical softwares like Finale?

Ah, Gregoria has *zero* kerning pairs ;-)

Here’s how it looks:

Best regards,

sergeym's picture

Word would skip Uniscribe for particular character sets, like Latin or Greek. If your characters are beyond these ranges, Word should rely on Uniscribe for correct shaping. What characters you use for musical notes?

If ligatures are being then Uniscribe is involved and Word should call it for positioning too. It is hard to tell why it does not work. May depend on script/langsys tags you use in GSUB or GPOS. Can you provide more details?


phatmatt's picture

Elena, I might be just as surprised as you! I only knew of the Meinrad fonts (and another one from the fellow who created the Night Office recebtly...can't remember the name of it now). I was very happy to see your font, and I really like the shape of the glyphs.

I was originally working on a software only project (in C#) that used a GUI to create the notation (I was a software engineer by training, not a typeface designer!). But I realized that a proprietary system to notate it was just not as flexible as utilizing DTP software already. I hadn't gotten as far as Finale, though Finale integration would make it much more usable I imagine...

I was hoping to keep Word compatibility enough to not require a seperate tool to notate it. But then again, I am not employing nearly as many neat 'calt's as you: (e.g., to specify a connecting line requires two height indicators, the start and the end).

How do your lines connect without any kerning? The puntums have to be pushed back to overlap a little bit, don't they? Or, now that I am looking at the PDF spec sheet for your font, do you simply not overlap the line with the punctum? Except for the podatus, I don't see another neume that has an interval of a fifth...

Thanks for your message... It's great to see your project. -B. Matthew

elena's picture

B., thank you for your comments.
Traditional western musical notation is covered by the unicode "symbols" range from U+1D100 to U+1D1FF:

At the beginning I considered of course using the standard and following the same process of the musical fonts I saw, which use components (noteheads + bars) to obtain the notes. The advantage of this method is *not* to consider the vertical position of the notes (which determines the pitch) in order to let the different musical softwares taking care of it. It is not considered as a technical limitation but as a feature of the encoding because it insures compatibility, since the elements encoded behave as characters (and not as glyphs...)

But as in our case the need was to work on layout applications (such as InDesign), for internal use and quality publications, this way resulted very complicated and tedious: combine a series of 5-numbers unicodes to obtain the neumes (sometimes quite clumsy in the way the elements join to make what originally is a single sign), use a script to adjust the position of the note on the stave (that has to be drawn separately) and switch font to enter liquescences, rhythmical signs, pauses, keys and anything else...

We tried instead to experiment a different system with the available font technology, opentype, to find an easy solution, practical and faster to type. Gregoria includes all the possible combinations at every height (there are 13 heights): the lines of the stave are integrated in every glyphs and spaces.
All the glyphs and spaces are modular to insure a plain rhythm and a constant line length... instead of thousand of kerning pairs it uses alternates glyphs with different left side-bearings.

How do you deal with the stave lines or vertical position in your font?


John Hudson's picture

I'm glad to see people working on Gregorian notation fonts. This is something I toyed with a couple of years ago, but I never had time to pursue it. My idea was specifically linked to an input method I was spec'ing which would allow the user to ender a neume type (single punctum, clivis, podatus, etc.) and then use number or cursor keys to assign the first note to a particular line of the staff. I never got further than making some notes though because of other projects that needed my attention. So I figure I'll just sing the stuff and someone else can look after the typesetting :)

elena's picture

Yes I've always noticed your typophile picture and wondered!

phatmatt's picture


I am using ligatures to map the notes to the different height positions, much like your method. My height characters are different (0-9 covers the standard range, and other characters provide the higher and lower vertical positions), but the idea is the same. 'p' is a punctum cuadratum, so ligatures 0p, 5p, Ap, etc. map to the punctum at different height values. 'P' maps to a podatus, and usually uses two height values: 35P, etc. A 'P' with only one height indicator only places the top of the podatus, which in my font is a little skinnier and a bit more curved underneath.

Many of the other single height glyphs (oriscus, punctum inclinatum, virga, first symbol of the clivis, etc.) follow the same pattern as the punctum. The porrectus is implemented like the podatus.

Then all of these can be connected using lines. The lines are specified using two height indicators like the podatus and porrectus, and I'm using kerning to adjust spacing. I was hoping to make the lines automatic using 'calt's, but I'm pretty new at creating any sort of typefaces, so I'm just trying to get it usable first.

Originally I was going to use non spacing characters for the staff, and have the neumes be composed of seperate glyphs on top. This would allow for different colored stave lines, but it seemed to be more of a hassle to consistently input glyphs. Besides, different colored stave lines is not really a high priority for me. Right now I just have a few stave line characters of multiple widths. I was originally going to make all the glyphs have consistent widths, but I'd prefer to keep the spacing more fluid if possible. To create consistent line lengths, I was considering using special line terminator glyphs that would be inserted at right-aligned tab marks and overlap with the glyphs before it. But I haven't finished this much yet.

But really I'm just doing this because, like John Hudson above, I just like singing and praying with Gregorian chant!

-B. Matthew

phatmatt's picture

As a follow up, here's what's going on that was frustrating my kerning attempts. I'm using Windows Vista, MS Office 2007, and InDesign.

The first problem seemed to be that fonts were getting cached by windows, so kerning changes weren't showing up in the applications correctly. This thread was what alerted me to it:

I followed the advice to simply change the font name on significant builds, at least while I'm developing. If anybody else has better advice, I'd love to hear it. (BTW, I do have the new WPF font cache service in Vista disabled).

Otherwise, it seems there was something that by reassigning the language/script settings did the trick (thanks for the tip Sergey). I don't know if it was a fontforge mistake or my own, but kerning kind of works now (see below).

I know I said that MS Word 2007 supports 'liga', but I noticed an interesting thing happening. As I was fixing errors reported by MS Font Validator, the 'liga's stopped working in Word 2007. It seems that if my font has a double quote glyph (0x22 I believe) the 'liga's don't work. If I remove that glyph from the font, the 'liga's work. Surely there's something going on underneath the hood (Word interpreting the font as a different script/lang maybe), surely I'm hacking things, but I still found it interesting. If anybody wants two hacked fonts, one that works with 'liga's in Word 2007 the other not, I can try to reproduce the issue. I don't know how any of this relates to earlier versions of Word.

On the other hand, Word doesn't seem to do the kerning correctly for 'liga's. It seems to use the kerning information for the first character rather than for the 'liga' glyph (using the unicode glyph itself works fine, but that kind of defeats the wole purpose of what I'm trying to do anyway). So after all that trying to simply fix kerning, it seems like MS Word support might be unreasonable anyway. I guess I should stop hacking and just make the font right anyway. :-P

Thanks for all the help/advice. -B. Matthew

Linda Cunningham's picture

As someone who has a deep love of Gregorian chant, I'm thrilled to hear that you folks are working on it. It's way past me technically (both from font-creation and singing perspectives!), but the fact that you are creating a better way to preserve this music is fabulous.


Miguel Sousa's picture

> I followed the advice to simply change the font name on significant builds, at least while I’m developing. If anybody else has better advice, I’d love to hear it.

Here's my best advice: Generate the font (and any further versions) directly into InDesign's own "Fonts" folder. When you switch back to InDesign you'll see your font refresh instantaneously. No need to keep changing the font's name. Simple! :)

PS: This works from FontLab, at least.

phatmatt's picture

Here’s my best advice: Generate the font (and any further versions) directly into InDesign’s own “Fonts” folder. When you switch back to InDesign you’ll see your font refresh instantaneously. No need to keep changing the font’s name. Simple! :)

Miguel, that's a cool tip and sounds quicker than copying the font to the Fonts folder everytime (which is what I've been doing as a neophite for some time now!). Unfortunately the font caching I'm having trouble with is Microsoft's, not Adobe's (which updates automatically when I copy into the Fonts folder anyway). :(

Miguel Sousa's picture

But my point is, since you're testing the font with InDesign as you go along developing it, there's no need to install the font in the OS's Fonts folder. You can simply make it available to InDesign and keep updating it over and over. This will prevent you from running into font cache problems.

Syndicate content Syndicate content