[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC 2020: blot diameter and positioning of flags

From: Jean Abou Samra
Subject: Re: GSoC 2020: blot diameter and positioning of flags
Date: Sat, 8 Aug 2020 18:55:23 +0200 (CEST)

On Thu, Aug 6, 2020 at 9:03 PM Carl Sorensen <>

> 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,
Hello Owen,
Disclaimer: the following is written from the viewpoint of someone with little k
nowledge in this area; I could well be way off beam.
If I understand correctly, there are two aspects in this project:
- support for using SMuFL fonts in LilyPond,
- making Emmentaler itself a SMuFL font so that it becomes usable in other SMuFL
-compliant programs.
Both parts are important, but if there needs to be a priority, I’d clearly favou
r the former. The latter depends on both the SMuFL people and other programs, wh
ich isn’t ideal for a time-bound project like yours.
>From what I understand, the ‘lily’ metadata object will basically encode some 
lues that are currently hard-coded, right? The advantage is that if SMuFL evolve
s, it would be much easier to get Emmentaler
in other programs. The drawback is the time and effort it takes you to fine-tune
. Plus, I frankly find it rather unlikely that the SMuFL standard evolves to mat
ch what we do in LilyPond.
So, I think it wouldn’t be too much of a problem if all that stays hard-coded in
 LilyPond instead of being accessed in JSON metadata. That is to say, I wouldn
’t mind the quick-and-dirty fix you mentioned at the beginning if that helps you
 get more time for review (which, as Urs mentioned in another thread, is a fairl
y long process in LilyPond).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]