|
From: | Owen Lamb |
Subject: | Re: SMuFL name mapping update, 9 July |
Date: | Tue, 13 Jul 2021 09:47:13 -0700 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
On 7/10/2021 9:38 PM, Werner LEMBERG wrote:
* Regarding `noteheads.uM2`, I don't see a problem with removing the hard-coded stems.That's good to hear. If we do, though, we'll have to reconcile breve/longa sidebars with Lily's customizable stems. I'm thinking we keep our breve glyphs for SMuFL compatibility, but in LP itself we draw breves and longas as noteheads.s0 with primitive sidebars.You mean with ligatures?
No--maybe I didn't explain very well.If we're going to remove our longa glyphs, we'll need to find a new way to draw them. The first possible solution would be to draw a font's breve notehead, then add a primitive stem to it the way we do for all other stemmed notes (which is a primitive drawing, not a glyph, so not a ligature). This, however, is a recipe for ugliness: a particular breve glyph's hardcoded sidebars are hardly guaranteed to line up with every possible custom LilyPond stem. (This issue is probably why we've hard-coded longa stems in the first place.)
To that end, I suggest drawing not only stems, but also the sidebars of longas, as well as breves for consistency, as primitive lines by default (again, not glyphs, so not ligatures). noteheads.s0 would serve as the notehead glyph for longas, breves, and semibreves. noteheads.sM1 would become unused by default, although we can certainly keep it around for SMuFL compatibility. For those SMuFL fonts that involve stylized breve sidebars, we should allow something like \useBreveGlyphs to override the new default behavior.
And... as I ramble on about this, it occurs to me that this should probably be handled as a totally separate enhancement issue. SMuFL doesn't care about longas, so we might as well give our longa "notehead" glyphs custom names for now and leave any feature enhancements (i.e. custom longa stems) for another day. I keep trying to overcomplicate things...
Noted. I'll see about restoring the failed matchups I deleted and go from there. (Thank goodness for Git!)By the way, it certainly makes sense in the forthcoming documentation of the LilyPond → SMuFL mapping to describe which glyphs are only approximations based on similar shapes, and which ones are truly identical. In other words, please preserve all comments, probably augmented with links to discussions, etc., etc. It seems that this project deserves a small database...
Owen
[Prev in Thread] | Current Thread | [Next in Thread] |