Re: GSoC 2020: blot diameter and positioning of flags

[Owen Lamb]

On Thu, Aug 6, 2020 at 9:03 PM Carl Sorensen <carl.d.sorensen@gmail.com>
wrote:

>
> I am a bit concerned that we are talking about eliminating some of what I
> think are superior design decisions of LilyPond in order to be SMuFL
> compliant.  I prefer the convention of attaching the flag to the center of
> the stem as opposed to the left-hand side.
>

(LilyPond's flags currently attach to the right edge of the stem, not the
center, but I get your point.) I admit, this was premature of me. I
temporarily changed the flag attachment anchor to the left side in order to
allow SMuFL fonts to be placed correctly without having to do anything
extra. It didn't preserve LilyPond's way of attaching stems, even if I
meant to refine the change later, and I now realize it would have been
better to seek guidance before changing anything of such consequence. At
any rate, the change is not meant to last.


> I much prefer the rounded corners on all Lilypond elements.
>

As do I.

I think that if we have to give those up to become SMuFL-compliant, we
> should maybe not become SMuFL-compliant.
>

I wholeheartedly agree. I will never suggest we get rid of these things.

Is it possible that we can maintain code for working with both SMuFL fonts
> and LilyPond fonts, each with its own specification type?  It seems like
> the extra information could be added to Emmentaler to make it SMuFL
> compliant, but it could also be used as-is under the LilyPond font
> specification.
>

This feels to me like a band-aid. If SMuFL isn't as universal as it could
be, it's better to improve it so it fits our needs instead of leaving some
of our features in a walled garden. I'd like to, if possible, extend SMuFL
so our features can be encoded in Emmentaler for other programs to use as
they wish as well. This would include, for instance, a way of knowing
whether a flag should be attached to the left or right edge of a stem.

I don't know if this is possible.  I don't even know if it's desirable.
> But every time I see you say "if we want to do it the LilyPond way, we need
> to get a change in the SMuFL spec", my concern with going full-SMuFL grows.
>

You have a point. I've been rather over-eager about proposing changes to
SMuFL, which I have no authority over.

In the (rather likely) case SMuFL chooses not to implement one or more of
the features we have, I can extend the standard unofficially for our own
font and have LilyPond look for any missing metrics in a "lily" metadata
object. If LilyPond sees this extra set of data, it'll perform things the
Lily way. If it doesn't see it, it'll perform things the SMuFL way. That
way, nothing will be lost in LilyPond's current functionality, even if we
can't go *full* SMuFL until SMuFL improves.

I believe the design decisions that Jan and Han-Wen made when creating
> LilyPond are excellent, and that 20 years of development, I've seen nothing
> that suggests we should move away from them.
>

Again, I agree. I plan to change nothing about LilyPond's current looks if
I can help it.

How much would it derail your project to adjust it to add SMuFL-compliance
> instead of replacing LilyPond with SMuFL?
>

Not too much, I think, as long as I can keep those changes I've made to
Lily-format that don't affect anything on the user-side--for instance, the
new glyph-lookup mechanism, which merely changes where each glyph is
stored, and the json format for the metadata file. Then I'd just need to
make sure LilyPond knows which kind of font it's looking at. For that, as I
said above, LilyPond can simply check whether a "lily" metadata object
exists in a font's .json file.

You were right to point out the change I made to the flag attachment. I
shouldn't have done that before I had more information. If any change in
LilyPond's ordinary functionality persists by the end of the summer, my
project will have failed.

That said, with these last couple weeks of work, I'm going to shift my
focus toward making what will already work fine with SMuFL work with SMuFL.
Any extra proposals to the standard, etc., can wait until the project is
over. In the meantime, I'll make space for missing features in a "lily"
metadata object, and go from there.

Thanks for your input,
Owen