I discover the amazing usefullness of the Bounding Box cut-outs points.
They are described here: https://w3c.github.io/smufl/gitbook/specification/bbox-cut-outs.html
Are these terms an invention of the SMuFL standard?
Or do they exist in typography?
I can’t find anything on these terms outside of SMuFL.
Is there a way to acces/control these points in a font program like FontForge?
The basic idea has existed since the beginning of typography, but I think the specifics are new.
If you want to typeset text, you need to adjust the horizontal space between adjacent letters. For example “AV” needs to have the V overlapping the A, but “AL” does not.
With moveable type, the physical letters had to fit together properly, so that they could be clamped into a frame containing a whole page of type. Therefore, there were different versions of a letter like “A” fixed onto different sized blocks of wood or metal, and the person assembling the page of type chose the correct versions to get the required letter spacing.
When hot metal type was introduced, the letters making up each line of the text were assembled by machine, and it was impractical to manually select the right variant of each letter. Instead of a being fixed to a solid block of material, the letters were fixed to two “rails” at the top and bottom, and these were cut back at each side depending on the individual letter. So an A would have the top rail cut back on both the left and right sides, and similarly the bottom rail of the V. Therefore, the combination AV fitted together more closely than a combination like AB, where there was no cut-back on any corners of the letter B.
This system was a compromise, since it wasn’t possible to independently adjust the spacing for every possible pair of letters, but it works pretty well except for very large sizes of type, which were still set up by hand.
Computer type faces made the system more general by taking a step backwards: each letter was “fixed” to an imaginary rectangle, but there was a table of information showing the horizontal spacing adjustment for every pair of characters in the font, and all the adjustments were independent of each other.
That works fine for text, but it is not so good for music, because musical symbols are not typeset only in horizontal lines. Some software calculated the exact shape of each character, and used that set the spacing, but that approach is relatively slow, and works best with software that doesn’t support a graphics user interface for interactively editing the score (for example Lilypond or Score).
The SMUFL idea is to fit the characters into “boxes” which are rectangles with (optional) rectangular cut-outs at each corner. That restricted shape is much quicker for the computer to check than an arbitrary shape with curved sides, and is “near enough” to be useful in practice. It is more general that the hot-metal technology, because the vertical height of each cut out can be independent, and different on different characters.
AFAIK the SMUFL cut-out points are not part of the basic font format specification - they are additional metadata which is only useful with applications that understand SMUFL. I guess that in font editing software, you could draw “guide lines” that are not actually part of the character to visualize the cut-outs, but until somebody writes a SMUFL-compliant font editor, there would still be a manual step to store the metadata in the correct format.
Bravo, Rob. I wholly subscribe your summary. In all likelihood more well-put than if I had a go.
Just to complete: as the specification states, the glyphsBBoxes are a class of the metadata file. You can specify the coordinate-pairs as appropriately-named anchors in FontForge, which can be then written into the metadata by the team’s own scripts, available in their Github repo.
Thanks a lot Rob, I really did not expect such a deep explanation.
It is very interesting.
This is then what I thought and these specific control points are a SMuFL creation.
BTW a very ingenious creation I would say!
Now for the practical part I guess I will have to do without these points.
I am trying to automatically manipulate glyphs and move them to specific positions with a formel.
For glyphs where the Bounding Box values (minimum x, minimum y, maximum x, maximum y) should be placed to specific values
it is not too difficult to find a formel because the values of these points can be accessed in FontForge.
But I have great difficulties to find a way to acces and manipulate other points.
For example the intersection points of the oval and the cross in a Coda glyph.
Such points are so easy to identify with the eyes but I can’t find a way to have acces to their values within FontForge.
And in fact these intersection points correspond quite exactly to the Bounding Box cut-outs of SMuFL.
It would be really usefull to have acces to these points in a font editor.
@ LSalgueiro
I am not sure if I completely understand what you suggest mostly because of my ignorance about Anchors.
I had a look but seing that they are used for composite glyphs I did not look deeper.
Are you suggesting that the BBox cut-outs points could be defined as Anchors in FontForge?
That’s what I do. Adding anchor points inside FF to indicate cutouts or anything else is absolutely not required, but I think you’ll be glad you learned how to use them so you can pull positional values from them when generating the metadata files.
Yes, exactly! It might seem confusing because anchor points serve their purpose in font design, but you can ignore all of that in the meantime. For this purpose, it’s as simple as placing an appropriately named anchor point in FontForge. The metadata script will just pull its position and convert it to a coordinate pair.
Actually, I’ve wondered many times why Dorico doesn’t just use real anchors in the font instead of relying on a metadata file. Virtually all the info in the metadata file can be represented just as clearly using modern OpenType font features. The only exception I can think of is the “engravingDefaults” list. Even then, you could store those in a custom subtable in the font. That’s what LilyPond does with all its metadata.
I’ll guess the answer is “semantics”. The corner of a cut-out is not logically an anchor, even if both are in some sense “a point with a name”.
Don’t forget that guy who started SMUFL was the same guy who decided that tempo marks, dynamics, etc, in Dorico are not “just text.”
As a secondary reason, would SMUFL want to locked into one font format - even if OpenType does seem to be the only real game in town right now?
If I’m not mistaken, Dorico isn’t really consuming most if not all OpenType features in a font, so I wonder whether this has something to do with Qt.
Anchors are hardly restricted to OpenType formats. I can understand that semantically they aren’t traditional composite glyph anchors, but in the SMuFL documentation, they are all called “anchors”, so I think it’s not so far-fetched to be asking fonts to have them, and to have a mitigation plan if they aren’t present. In reality, they are taking the place of kerning data, but in a 2-dimensional layout that’s harder to simply put a value to and using a simple anchor point is very effective at defining the region.
While Dorico does indeed it ore most of the metadata file (which is even more puzzling and frustrating to me, but anyway), it doesn’t ignore everything and it would be useful to know precisely which sets of data are actually being used by Dorico.
@ LSalgueiro and tisimst
I spend many hours trying to practically understand what you suggest but without success.
For example I added an Anchor point to a Glyph in FontForge, recreated the Metadata with the R. Piechaud script and indeed the Anchor was recognised.
But editing the xy values of the Anchor point in the metatada file did not seem to have any consequece on the position of the glyph later in the score.
So I probably do not really understand what was suggested.
You’re not alone, friend. Dorico isn’t actually consuming those values. See the thread created just today by timist, most likely motivated by this one.
If Dorico isn’t using the cutout data, what is the algorithm that stacks accidentals like this? The font in the image is Bravura.
(Ahhh… maybe the Engraving rules for Accidentals, Stacking, advanced options answers the question: Dorico looks at the shape of the glyphs, rather than the box cut-out data.)
Dorico does use cut-out values for noteheads and accidentals, but it doesn’t read them in real-time. The data is stored in the accidental and notehead definitions in your project. The cut-outs will be updated when you use Engrave > Music Fonts to change to another SMuFL-compliant music font, but changing the JSON metadata file will have no direct effect.
@ Daniel
Thank you for chiming in.
Trying to understand the underlying of what you write!
When you write “Dorico does use cut-out values for noteheads and accidentals”
From where does Dorico read these values when a metadata file containing these values is existing?
From the font itself or from the metadata file?
If Dorico indeed reads the values from the metadata file, does it imply that these values can be different in the font and in the metadata file, meaning that they can be edited in the metadatafile?
If so, do I understand it right about Dorico not reading these values in real-time:
When one makes some changes to a metatadata file, after one has already used a font,
in order to have these changes reflected in Dorico, one has to first unload the music font and then reload it, right?
In this thread What SMuFL metadata does Dorico actually use? - Dorico - Steinberg Forums you already gave usefull informations but
could you precise wether other glyphsWithAnchors values than the cut-outs are read and used by Dorico?
Dorico reads the cut-out values from the JSON metadata file. Although Luis and Abraham assert that it would be possible to encode this kind of metadata in custom font tables in OpenType fonts, and I’m sure they’re right, SMuFL does not stipulate the use of custom tables in fonts since many applications cannot read that kind of data (Dorico is among them). To get Dorico to read new values from the metadata file, you would need to choose a different music font and then re-choose the one with the updated metadata. You would also need to restart Dorico after changing the metadata file because the program only loads the metadata files once, at start-up.
Thanks Rob Tuley detailled explanations and thanks the explanations here: https://w3c.github.io/smufl/gitbook/specification/bbox-cut-outs.html
I understand the use of “cutOuts” anchor points for accidentals.
But I still do not understand their use for noteheads.
In Bravura there are only two noteheads with these points: “noteheadBlack” and “noteheadHalf”
Could someone explain for which situation(s) the anchor points “cutOutNW” and “cutOutSE” for “noteheadBlack” and “noteheadHalf” are necessary?
They are used by Dorico in a small number of specific situations for tucking voices and accidentals.
Thank you for your answer.
I am not sure what “tucking voices” mean?
I post a pic where I added manually these cutOuts to the Bravura glyph “noteheadBlack” (uniE0A4) according to the values found in the Bravura json file.
Both anchor points are inside or outside of the glyph and do not correspond to the clear explanations found at https://w3c.github.io/smufl/gitbook/specification/bbox-cut-outs.html for the accidentals.
I must confess that it is difficult for me to understand where I should place these Anchor Points in a new font I am working on.
I could of course place them to a position aproximately similar to the Bravura glyph but this would be an almost “half-blind” positioning as I really have no idea which is the exact aim of the points because despite your explanations I am not able to visualize which kind of specific situations it can be.
I would be of course gratefull for some visual explanations of the specific situations you mention.
As I understand the situation, when two voices cross, the head of the upper voice may need to tuck under the head of the lower voice above and squeeze in closer to the stem of the lower note (or vice-versa).
