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
>
> > 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,
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"
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
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
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
> 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
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
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).
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
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
>
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
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
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.
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
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
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
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
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*
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
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
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
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.
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.
>
>
> 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
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
26 matches
Mail list logo
