Re: Accidentals' font

[Kieren MacMillan]

Hi Paolo,

> > I can provide other examples if you are interested.
> Then it is pretty strange that you were interested in commenting on something 
> that is not of your interest ;-)

I didn’t say the first example wasn’t of my interest.
You seem to have difficulty reading.  ;-)

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Accidentals' font

[Paolo Prete]

On Sun, Jul 5, 2020 at 12:14 AM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi Paolo,
>
> > What would you consider more readable?
>
> The Feta version.
> The only objection I have is to the kerning in mf — otherwise, I think the
> Feta version is more readable.
>
>
Not so trivial to judge. In my knowledge a dynamic is really readable when
it's strongly coupled to the note it belongs to.
Otherwise, what is readable is the glyph. When you have m and f separated,
the glyph itself it's more readable, but not the pair note-dynamic.
And playability doesn't privilege aesthetics...



> > I can provide other examples if you are interested.
>
>
Then it is pretty strange that you were interested in commenting on
something that is not of your interest ;-)




>

Re: Accidentals' font

[Kieren MacMillan]

Hi Paolo,

> What would you consider more readable?

The Feta version.
The only objection I have is to the kerning in mf — otherwise, I think the Feta 
version is more readable.

> I can provide other examples if you are interested.

I’m not… but maybe others are.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Accidentals' font

[Paolo Prete]

>
>
> About this question, I gave an answer to Han-Wen. For example, I consider
> objective data that a fraction where the mumerator is not joined to the
> denominator is more readable.
> Also, look at the attached image in response to Kevin (clefs) with the red
> lines. I consider it objective as well.
>
>
>

Also: look at the attached image.
What would you consider more readable? In this case, the more a dynamic is
restricted to its column, the more it is readable (in the sense: it's more
playable because you can better understand what is its corresponding note).

In order to do this, the chars "m" and "f" were put very close.
Also: in Feta they are separated, but they are not separated in the mp
dynamic...

I can provide other examples if you are interested.


testmfmp.pdf
Description: Adobe PDF document

Re: Accidentals' font

[Paolo Prete]

On Sat, Jul 4, 2020 at 10:45 PM Carl Sorensen 
wrote:

>
>
> On Sat, Jul 4, 2020 at 2:31 PM Paolo Prete  wrote:
>
>> 
>> I think there is an incomprehension in the meaning of my words.
>> Unfortunately this does not depend on Lilypond but on commercial logic in
>> the production of musical fonts today. Today it seems to me that music
>> software producers are more interested in the captivating aspect of fonts
>> than in their actual readability. This is normal, otherwise they could not
>> sell their products. Consequently, this is why there is a great
>> proliferation of bold fonts of the "plate engraving" type. If you look at
>> the trill glyph in Gonville, it appears much simpler than those that are
>> commonly used. Commercially I think it would have little success. But
>> Gonville's trill glyph does not aim to be captivating; it aims to be more
>> readable.
>> Lilypond currently has two possibilities:
>>
>> 1) use the Feta font (---> "plate engraving approach") as do the other
>> notation softwares.
>>
>> 2) use the Gonville font (---> "readability / playability approach")
>>
>>
> Do you have any objective data that says Gonville is more
> readable/playable than Feta?  Or is this your opinion?
>
> Carl
>
>

About this question, I gave an answer to Han-Wen. For example, I consider
objective data that a fraction where the mumerator is not joined to the
denominator is more readable.
Also, look at the attached image in response to Kevin (clefs) with the red
lines. I consider it objective as well.

Re: Accidentals' font

[Urs Liska]

Am Samstag, den 04.07.2020, 10:06 -0500 schrieb Karlin High:
> On 7/4/2020 5:55 AM, Paolo Prete wrote:
> > Just leave Feta as a native font and insert a dummy
> > wrapper for Gonville in the ./configure. This does not require any
> > development, nor uniformity in the coding standard and can be
> > easily added
> > to the source tree.
> 
> This discussion is reminding me of the Google Summer of Code project 
> proposal, "Support for Style Sheets."
> 
> "
> LilyPond’s engraving output can be tweaked to the least detail, and
> one 
> important addition in recent years was the ability to use
> alternative 
> notation fonts. It is possible to create reusable modules for “house 
> styles”, but this project aims at bringing this to a new level by 
> creating a convenient extension package with support for creating, 
> applying, and sharing modular style sheets.
> "
> 
> 
> That looks to me like there IS community support for having ways to 
> change the look-and-feel of LilyPond's output, depending how the 
> development goals are defined and presented.

I just want to point out that there's an openLilyLib package 
https://github.com/openlilylib/notation-fonts which allows you to use
any installed (i.e. compatible) notation font as easily as

\include "oll-core/package.ily"
\loadPackage notation-fonts
\useNotationFont lilyjazz

This loads a default stylesheet provided for lilyjazz, but you can also
specify custom styles with

\useNotationFont \with {
  stylesheet = #'my-custom-style.ily
} haydn

The repository with the old OFL versions of Abraham Lee's work (which
includes Gonville BTW) has been mentioned, and Frescobaldi provides a
easy-to-use dialog to install and choose notation fonts with built-in
preview function.

Urs

Re: Accidentals' font

[Kieren MacMillan]

Hi Carl (et al.),

> Do you have any objective data that says Gonville
> is more readable/playable than Feta?  Or is this your opinion?

Must be his opinion, because I’ve put scores using Gonville and Feta in front 
of the same players, and many of them have said that Feta is easier to read 
(especially under pit-lighting conditions).

=)

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Accidentals' font

[Carl Sorensen]

On Sat, Jul 4, 2020 at 2:31 PM Paolo Prete  wrote:

> 
> I think there is an incomprehension in the meaning of my words.
> Unfortunately this does not depend on Lilypond but on commercial logic in
> the production of musical fonts today. Today it seems to me that music
> software producers are more interested in the captivating aspect of fonts
> than in their actual readability. This is normal, otherwise they could not
> sell their products. Consequently, this is why there is a great
> proliferation of bold fonts of the "plate engraving" type. If you look at
> the trill glyph in Gonville, it appears much simpler than those that are
> commonly used. Commercially I think it would have little success. But
> Gonville's trill glyph does not aim to be captivating; it aims to be more
> readable.
> Lilypond currently has two possibilities:
>
> 1) use the Feta font (---> "plate engraving approach") as do the other
> notation softwares.
>
> 2) use the Gonville font (---> "readability / playability approach")
>
>
Do you have any objective data that says Gonville is more readable/playable
than Feta?  Or is this your opinion?

Carl

Re: Accidentals' font

[Kieren MacMillan]

Hi Carl (et al.),

> I agree with Kevin.  You do not speak (even in this email) as if it is your
> opinion; you speak as if it is an undisputed fact.

+1

> I am, however, getting somewhat weary of your posts that say, in essence,
> "LilyPond does X incorrectly.  And it is obvious to anybody that only an
> idiot would do it that way, so LilyPond needs to change."
> […] that is the feeling I get when I read many of your posts.

+1

> because the justification for wanting Gonville is not expressed as
> a preference, but instead as a defect in Feta (which should
> apparently be obvious to everybody), I just tune it out.

+1

Maybe Paolo should add a disclaimer to his signature, like David K does?  ;)

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Accidentals' font

[Paolo Prete]

On Sat, Jul 4, 2020 at 8:46 PM Carl Sorensen 
wrote:


>
>
>> All the fonts on the earth have many issues. If you look at the score of
>> Debussy, it has *many* and *many* issues, and it was one of the best
>> engraving techniques at his time.
>>
>
> Again, in your opinion it had *many* and *many* issues.
>
>


perhaps we give two different meanings and weights to the word "issue".
Note that I have said that Debussy's edition was excellent in those days.
And the engraving company (Durand) one of the most important in history.
Don't give the word "issue" a negative meaning. I think that in this type
of task, "issue" is the most neutral thing in the world. That said, you say
that I should write "in my opinion".
But look at the first six bars of the prelude:

https://github.com/paolo-prete/Spontini/blob/master/examples/debussy-frag-1.jpeg

Is the dangling 1/4 rest at bar 4 an "issue" in my (Paolo) opinion or is it
an "issue" tout-court?
And what about the end of the slur of bar 2 at the beginning of bar 3?
And what about the triple hairpin on two notes in bar 3?
And what about the beam that overlaps the stem at bar 6?



> I appreciate your interest in LilyPond.  And I appreciate your willingness
> to develop a self-contained html editor to allow easy creation of visual
> tweaks, which are then captured in the source.  I know that you use that,
> and I expect others will use it as well.  Thank you for your contribution.
>
> I am, however, getting somewhat weary of your posts that say, in essence,
> "LilyPond does X incorrectly.  And it is obvious to anybody that only an
> idiot would do it that way, so LilyPond needs to change."
>
> I realize that my paragraph above is hyperbole, not literal.  And yet,
> that is the feeling I get when I read many of your posts.  The tenor of
> your message makes it difficult for me to appreciate the value of your
> observations.  For example, in the particular case of this request, it
> might be reasonable to ship a "gonville-install" script with LilyPond that
> could be run to download and install Gonville (I'm not sure what all the
> technical challenges of this are).  And it might be reasonable to have the
> gonville-install script set the default font for LilyPond to be Gonville
> (again, I don't know what all the technical challenges of this approach
> are).  But because the justification for wanting Gonville is not expressed
> as a preference, but instead as a defect in Feta (which should apparently
> be obvious to everybody), I just tune it out.
>
> Again, I sincerely thank you for your contributions to LilyPond.
>
>
I think there is an incomprehension in the meaning of my words.
Unfortunately this does not depend on Lilypond but on commercial logic in
the production of musical fonts today. Today it seems to me that music
software producers are more interested in the captivating aspect of fonts
than in their actual readability. This is normal, otherwise they could not
sell their products. Consequently, this is why there is a great
proliferation of bold fonts of the "plate engraving" type. If you look at
the trill glyph in Gonville, it appears much simpler than those that are
commonly used. Commercially I think it would have little success. But
Gonville's trill glyph does not aim to be captivating; it aims to be more
readable.
Lilypond currently has two possibilities:

1) use the Feta font (---> "plate engraving approach") as do the other
notation softwares.

2) use the Gonville font (---> "readability / playability approach")

The two aspects are complementary and I have hardly seen such an accurate
and meticulously made font as Gonville, in the sense of readability /
playability. This would certainly give, in my opinion, a strong
professional touch to the software.

And I also want to thank you, of course, for your contribution to Lilypond.
This is beyond doubt. Thanks to Lilypond I am free from the slavery of the
WYSIWYG. I really can't think of using better alternative software than it.

Re: Accidentals' font

[Carl Sorensen]

On Sat, Jul 4, 2020 at 9:25 AM Paolo Prete  wrote:

> On Sat, Jul 4, 2020 at 4:43 PM Kevin Barry  wrote:
>
> > > Again, I hope I am not unpleasant and polemic
> >
> > In my opinion, you are being both. If your goal was genuinely to
> > encourage improvements in LilyPond, then I hope it's clear from the
> > response that you are going about it in a poor way. Acting like it's
> > obvious that LilyPond's default font is badly designed is insulting,
> >
>
> I don't think so. Saying that Feta font has many issues, is absolutely not
> insulting.
>

I agree with Kevin.  You do not speak (even in this email) as if it is your
opinion; you speak as if it is an undisputed fact.

Personally, I prefer Feta to Gonville.  But I cannot say that Feta is
superior to Gonville, it is just my preference.


> All the fonts on the earth have many issues. If you look at the score of
> Debussy, it has *many* and *many* issues, and it was one of the best
> engraving techniques at his time.
>

Again, in your opinion it had *many* and *many* issues.


> For example, many excellent engravers do use the "Ped." classical symbol,
> IMHO so wide and messy. But they are excellent in any case.
> Music engraving is *in itself* an ocean of issues. Doing a good engraving
> is something like a Carthusian task and only in recent years things are
> generally improved, thanks to the technology.
> And we are very far from a shared "standard".
>

Since we are far from a shared standard, it is not helpful to speak in
absolute language about the performance of LilyPond.  Just because it
doesn't match your preference doesn't mean it's wrong.  Yet your emails
consistently speak of things being wrong, not just being different from
your preference.

I find it interesting that you accused me earlier of being harsh and
polemic, but you appear unable to recognize when your messages are harsh
and polemic.

I appreciate your interest in LilyPond.  And I appreciate your willingness
to develop a self-contained html editor to allow easy creation of visual
tweaks, which are then captured in the source.  I know that you use that,
and I expect others will use it as well.  Thank you for your contribution.

I am, however, getting somewhat weary of your posts that say, in essence,
"LilyPond does X incorrectly.  And it is obvious to anybody that only an
idiot would do it that way, so LilyPond needs to change."

I realize that my paragraph above is hyperbole, not literal.  And yet, that
is the feeling I get when I read many of your posts.  The tenor of your
message makes it difficult for me to appreciate the value of your
observations.  For example, in the particular case of this request, it
might be reasonable to ship a "gonville-install" script with LilyPond that
could be run to download and install Gonville (I'm not sure what all the
technical challenges of this are).  And it might be reasonable to have the
gonville-install script set the default font for LilyPond to be Gonville
(again, I don't know what all the technical challenges of this approach
are).  But because the justification for wanting Gonville is not expressed
as a preference, but instead as a defect in Feta (which should apparently
be obvious to everybody), I just tune it out.

Again, I sincerely thank you for your contributions to LilyPond.

Sincerely,

Carl Sorensen

Re: outlet v. context

[Dan Eble]

On Jul 4, 2020, at 11:15, David Kastrup  wrote:
> 
> While you are at it: I don't see that there is lots of sense in having
> get_context () for some classes and context () for others.  Or
> get_parent_context () for some and get_daddy_context () for others.
> Generally the get_ prefix seems a bit spurious: given that we use the
> naming convention field_ for data members, calling the read accessor
> field () seems like it should always be workable.

Ugh.  I'm working on the outlet/context change now (involving lots of rebasing 
of my work in progress).  I'll probably be unwilling to do more than that 
immediately, but regardless, I should let others weigh in on get_foo() v. foo() 
first.
— 
Dan

Re: Accidentals' font

[Paolo Prete]

On Sat, Jul 4, 2020 at 4:43 PM Kevin Barry  wrote:

> > Again, I hope I am not unpleasant and polemic
>
> In my opinion, you are being both. If your goal was genuinely to
> encourage improvements in LilyPond, then I hope it's clear from the
> response that you are going about it in a poor way. Acting like it's
> obvious that LilyPond's default font is badly designed is insulting,
>

I don't think so. Saying that Feta font has many issues, is absolutely not
insulting.
All the fonts on the earth have many issues. If you look at the score of
Debussy, it has *many* and *many* issues, and it was one of the best
engraving techniques at his time.
For example, many excellent engravers do use the "Ped." classical symbol,
IMHO so wide and messy. But they are excellent in any case.
Music engraving is *in itself* an ocean of issues. Doing a good engraving
is something like a Carthusian task and only in recent years things are
generally improved, thanks to the technology.
And we are very far from a shared "standard".

And for the clef test I actually don't
> perceive any real difference other than the "C" for the time signature
> (and again, I prefer the thicker version).
>
>
I attach a clearer image of what I consider the issue (this in response to
Han Wen too, because my previous example was not clear). Red lines show how
the two areas overlap.


feta-gonville.pdf
Description: Adobe PDF document

Re: outlet v. context

[David Kastrup]

Dan Eble  writes:

> virtual Context *get_outlet () const;
> virtual void set_context (Context *);
> . . .
> void init_context (Music *, Context *);
> . . .
> void substitute_outlet (Context *from, Context *to);
>
> This is driving me nuts.  Is anyone attached to the term "outlet"?  If
> so, please suggest how I might modify my thinking to avoid typing
> "get_context" when I should have typed "get_outlet".

While you are at it: I don't see that there is lots of sense in having
get_context () for some classes and context () for others.  Or
get_parent_context () for some and get_daddy_context () for others.
Generally the get_ prefix seems a bit spurious: given that we use the
naming convention field_ for data members, calling the read accessor
field () seems like it should always be workable.

-- 
David Kastrup

Re: Accidentals' font

[Karlin High]

On 7/4/2020 5:55 AM, Paolo Prete wrote:

Just leave Feta as a native font and insert a dummy
wrapper for Gonville in the ./configure. This does not require any
development, nor uniformity in the coding standard and can be easily added
to the source tree.


This discussion is reminding me of the Google Summer of Code project 
proposal, "Support for Style Sheets."


"
LilyPond’s engraving output can be tweaked to the least detail, and one 
important addition in recent years was the ability to use alternative 
notation fonts. It is possible to create reusable modules for “house 
styles”, but this project aims at bringing this to a new level by 
creating a convenient extension package with support for creating, 
applying, and sharing modular style sheets.

"


That looks to me like there IS community support for having ways to 
change the look-and-feel of LilyPond's output, depending how the 
development goals are defined and presented.

--
Karlin High
Missouri, USA

Re: Accidentals' font

[Kevin Barry]

> Again, I hope I am not unpleasant and polemic

In my opinion, you are being both. If your goal was genuinely to
encourage improvements in LilyPond, then I hope it's clear from the
response that you are going about it in a poor way. Acting like it's
obvious that LilyPond's default font is badly designed is insulting,
and hiding insults behind your "opinion" isn't fooling anyone - it
just comes across as superior / talking down. If fonts were so easily
comparable as you are pretending, then we wouldn't have so many of
them.

The philosophy behind the design of LilyPond's default font was to
imitate plate engraving (which results in thicker lines than computer
engraving, partly because of "squeeze"), not to imitate another
computer font like Gonville, so all this Gonville talk is hot air. If
you don't like them that's not the fault of the font.

Regarding the attachments: in my opinion the lines in the sharp symbol
in Gonville are too thin and too close together - I have to squint at
it to see the gap properly. And for the clef test I actually don't
perceive any real difference other than the "C" for the time signature
(and again, I prefer the thicker version).

Kevin

outlet v. context

[Dan Eble]

virtual Context *get_outlet () const;
virtual void set_context (Context *);
. . .
void init_context (Music *, Context *);
. . .
void substitute_outlet (Context *from, Context *to);

This is driving me nuts.  Is anyone attached to the term "outlet"?  If so, 
please suggest how I might modify my thinking to avoid typing "get_context" 
when I should have typed "get_outlet".
— 
Dan

Re: Accidentals' font

[Jan Nieuwenhuizen]

Han-Wen Nienhuys writes:

Hi!

>> 7) Look at the trill glyph: it's simpler, cleaner and less "baroque",
>
> Maybe Jan can comment. The comment says it's based on a Saint Saens
> Cello concerto, which I can't recall ever having seen.

Yes, I have some recollection of that.  You are probably aware that some
of the inspiration of the Feta font came from the fact that in those
days the vast majority of computer music engravings were way too light.

I can imagine that we may have overshot a little bit, just like I can
imagine that a subsequent reaction to LilyPond's blackness/heaviness
(especially in this era where people have become more accustomed to
light engravings) will probaly also overshoot a bit; certainly to my
taste.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Accidentals' font

[Lukas-Fabian Moser]

Hi Han-Wen,


6) Look at the glyph of forcing: it forms a single word, and not the union
of three different characters (which is very distracting, in my opinion)

what is 'forcing' ?
I assumed it meant sfz, coming from an Italian native speaker - Paolo, 
please correct me if I'm wrong.

7) Look at the trill glyph: it's simpler, cleaner and less "baroque",

Maybe Jan can comment. The comment says it's based on a Saint Saens
Cello concerto, which I can't recall ever having seen.


Seems plausible: Everybody (tm) plays the 1st concerto, and at least 
15-20 years ago, everybody (tm) used the Durand edition. There you find:


Not really identical to LilyPond's current

but certainly related.

Lukas

Re: Accidentals' font

[Han-Wen Nienhuys]

On Fri, Jul 3, 2020 at 11:42 PM Paolo Prete  wrote:
> *All* my opinions are personal opinions. And I don't expect they will be
> followed or implemented.

If you really expect that, why bother sending this email?

Let's all just assume that they're not just your personal opinions,
but that you have found genuine defects in the font. We're not going
to adjust glyphs because they don't conform to your opinion. We can
adjust glyphs if we find there are bugs in them.

> Meanwhile, for anyone interested I focus on some aspects that IMHO make
> that font really desirable for Lilypond, at least as an option. Be free to
> agree or not agree: here is my list
>
> 1) Look at the treble clef. IMHO Lilypond doesn't need to be so high, and
> in fact the author of the font has reduced its height. Using a treble clef
> higher than necessary leads to spacing problems between staves.

I actually doubt this. The clef is at the start of the line, and there
are usually no things sticking out of the bottom of the at the start
of the previous line.

> 2) In general, for keys, there is no need to use bold glyph. The default
> bold glyphs, which are Bravura's philosophy (AFAIK), were fine when

Can you explain what you mean with "bold" glyphs. The accidentals only
exist in one flavor.

> 3) Look at the time signature. In the Feta font the two numbers overlap and
> can be annoying at the sight, IMHO. This problem was solved by the Gonville
> font.

Can you file a bug with an image? Over here, the digits do not overlap
with each other, but do overlap slightly with the staff lines. (see
attachment).

> 4) Look at the sharp glyph: it is reduced in width, saving space and
> remaining perfectly legible at the same time.

The gonville font is well done, but we usually base formatting
decisions on plate engravings. Could you do some measurements to
demonstrate what ranges of dimensions (relative to staff space) are
common?

> 5) Look at the flat glyph: the horizontal line has been reduced in
> thickness, which once again pairs well with lighter staves and stems.

The flat glyph has no horizontal line. You can see the glyph it was
based on over here:

http://lilypond.org/doc/v2.19/Documentation/essay/engraving-details.en.html

note that the feta glyph is actually lighter than its inspiration.

> 6) Look at the glyph of forcing: it forms a single word, and not the union
> of three different characters (which is very distracting, in my opinion)

what is 'forcing' ?

> 7) Look at the trill glyph: it's simpler, cleaner and less "baroque",

Maybe Jan can comment. The comment says it's based on a Saint Saens
Cello concerto, which I can't recall ever having seen.

> 8) Look at the bequadro glyph: the Feta one is too large compared to the
> NoteHead and this has also been corrected in the gonville font.

Scans? "Too large": do you mean too wide, or too high?

> I could go on with many other details.

Thanks. I could go on asking questions, but I am really looking for
data rather than opinions.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: question about configure for reg tests

[Dan Eble]

On Jul 4, 2020, at 07:09, Jonas Hahnfeld  wrote:
> 
>> Should I be using the same options as the CI image is? (and if so, can 
>> you tell me what they are in case I have missed any)?
> 
> As said above, I don't think it makes a difference. If you want to, Dan
> recently added "autogen.sh --ci" which gets you exactly those flags 

Jonas' response came in while I was halfway through composing mine.  I agree 
with all of it.
— 
Dan

Re: question about configure for reg tests

[Jonas Hahnfeld]

Hi James,

Am Samstag, den 04.07.2020, 11:48 +0100 schrieb James Lowe:
> Hello,
> 
> I noticed that the Docker image is using a few configure options that I 
> do not use when I make/make check.

most of the flags in CI are about speeding up the build and reducing
size (in particular disabling debug symbols and enabling the GS API).
Both should make no difference for the regression tests. --enable-
checking is probably worth to have.

> Likewise I notice that while I use 
> configure --disable-optimising, the image does not (as far as I can tell 
> the disable-optimising option is specifically for reg test processing).

--disable-optimising is a lie, and so is --disable-debugging. If I do:
 $ ../src/configure --disable-debugging --disable-optimising
[...]
 $ grep CXXFLAGS config.make 
CONFIG_CXXFLAGS = -g -O2  [...]

that's certainly not what I expect. The reason is that autoconf adds
default code that sets CFLAGS="-g -O2" unless the user passes a custom
value of CFLAGS. In my opinion, that contradicts the purpose of the
flags and I intend to remove them soon.

> Should I be using the same options as the CI image is? (and if so, can 
> you tell me what they are in case I have missed any)?

As said above, I don't think it makes a difference. If you want to, Dan
recently added "autogen.sh --ci" which gets you exactly those flags 

Jonas


> Thanks
> 
> James


signature.asc
Description: This is a digitally signed message part

Re: Accidentals' font

[Paolo Prete]

>
> > This addition does not involve any development. All the stuff is already
> > developed. Just simply, AFAIK, add the fonts to their respective
> > directories, as I have already done.
>
> Here are some things to consider:
>
> * You point to modern printers generating thinner lines. However, the
> design objective of Feta was to mimic plate engraving with thicker
> lines. In that sense it is working as intended, even if it is not your
> preferred style.
>
>
I don't think so.

I'm sorry if I can seem overly punctilious, pedantic and unpleasant (and I
repeat that these are my * personal * observations), but look at this score:

https://ks.imslp.net/files/imglnks/usimg/0/0c/IMSLP521885-PMLP2394-Debussy_Claude-Pr%C3%A9ludes_1er_Livre_Durand_7687_scan.pdf

The lines are thick and it's plate engraving dated 1902!
The numerator and the denominator of the time signature are bold enough for
these thicknesses but never overlap, unlike Feta.
See also the trill glyph on page 44. You can notice that Feta has too thin
curves combined with too thick curves, while in Debussy's score all the
trill curves are modeled on a more or less uniform thickness, consistent
with the thickness of the lines.



> (I do accept the blame for the font being a haphazard collection of
> individual glyphs I happened to like, rather than a coherent
> ensemble.)
>
> * LilyPond is built from source. Although rare, it does happen that we
> tweak glyphs (for example, see the work that Owen Taylor is doing for
> Smufl support).  This process doesn't work well with Gonville, as it
> is not generated with Metafont. How do you envision development
> happening with Gonville as a standard font?
>
>

This is not a problem. Just leave Feta as a native font and insert a dummy
wrapper for Gonville in the ./configure. This does not require any
development, nor uniformity in the coding standard and can be easily added
to the source tree. Using a flag like --with-gonville-font you can also be
sure that if the Gonville src is not aligned with the source of Lilypond,
the compilation will give an error. At this point the user will be able to
remove the flag and continue compiling. There are many similar examples.
For example x264 is not a native codec for ffMPEG, but it is the * de facto
* codec for it and is added to the project via a simple wrapper.

(politically correct Disclaimer ;-) ):
Before anyone gets annoyed by all these considerations, I repeat that I am
all personal opinions, without wanting to convince anyone but it is my goal
only to invite to meditate on the subject. And in particular they are
determined by the fact that, from what I have observed, the work on
Gonville is truly impressive and meticulous. I think anyone can observe
these details.




>

question about configure for reg tests

[James Lowe]

Hello,

I noticed that the Docker image is using a few configure options that I 
do not use when I make/make check. Likewise I notice that while I use 
configure --disable-optimising, the image does not (as far as I can tell 
the disable-optimising option is specifically for reg test processing).


Should I be using the same options as the CI image is? (and if so, can 
you tell me what they are in case I have missed any)?


Thanks

James

Re: Accidentals' font

[Han-Wen Nienhuys]

On Fri, Jul 3, 2020 at 11:42 PM Paolo Prete  wrote:
> I could go on with many other details.
> Which is of course my simple opinion; in any case I'm not asking to
> implement anything. I'm just asking to add the excellent work done by the
> author of the Font. A very meticulous work for which I thank him very much.
>
> This addition does not involve any development. All the stuff is already
> developed. Just simply, AFAIK, add the fonts to their respective
> directories, as I have already done.

Here are some things to consider:

* You point to modern printers generating thinner lines. However, the
design objective of Feta was to mimic plate engraving with thicker
lines. In that sense it is working as intended, even if it is not your
preferred style.

(I do accept the blame for the font being a haphazard collection of
individual glyphs I happened to like, rather than a coherent
ensemble.)

* LilyPond is built from source. Although rare, it does happen that we
tweak glyphs (for example, see the work that Owen Taylor is doing for
Smufl support).  This process doesn't work well with Gonville, as it
is not generated with Metafont. How do you envision development
happening with Gonville as a standard font?

> Hope this can help.

I think the most practical solution is to wait for Smufl support for
LilyPond, which should make it easier to use a wide array of music
fonts.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

PATCHES - Countdown for July 4th

[James Lowe]

Hello,

Here is the current patch countdown list. The next countdown will be on 
July 6th.


A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority


 Push:

!213 Fix spurious warning about an empty score - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/213

!211 Make duration parsed as music arg sets default duration - David Kastrup
https://gitlab.com/lilypond/lilypond/-/merge_requests/211

!210 Doc-Usage: Small fixes and clarifications regarding lilypond-book 
usage with texinfo - Michael Käppler

https://gitlab.com/lilypond/lilypond/-/merge_requests/210

!209 DOC: Changes to the documentation on using Make with LilyPond - Fr. 
Samuel Springuel

https://gitlab.com/lilypond/lilypond/-/merge_requests/209


 Countdown:

!215 Fix negative spacing when stacking stencils - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/215

!214 Music_iterator cleanup - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/214


 Review:

!219 Return SCM_UNSPECIFIED rather than SCM_UNDEFINED - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/219

!218 Fix `-dgs-never-embed-fonts` - Masamichi Hosoda
https://gitlab.com/lilypond/lilypond/-/merge_requests/218

!217 Stepmake: Fix uninstall process - Michael Käppler
https://gitlab.com/lilypond/lilypond/-/merge_requests/217


 New:

No patches in New at this time.


 Waiting:

!204 Move parallel processing to lilypond-book - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/204

!202 Fix xrefs in learning manual - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/202

!200 Add snippet translations - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/200



***

Regards,

James