bug-lilypond
[Top][All Lists]
Advanced

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

Re: Issue 1752 in lilypond: redesigning G clef in our Feta font


From: Carl Sorensen
Subject: Re: Issue 1752 in lilypond: redesigning G clef in our Feta font
Date: Mon, 25 Jul 2011 16:36:47 -0600

On 7/24/11 5:43 PM, "address@hidden" <address@hidden>
wrote:

> 
> 
> Comment #26 on issue 1752 by address@hidden: redesigning G clef in
> our Feta font
> http://code.google.com/p/lilypond/issues/detail?id=1752
> 

> 
>> In order to address the difference of opinion, we have two proposals.  The
>> first is to allow an override to switch the glyphs.  Trevor is strongly
>> against it; it would lead to a multiplicity of overrides.  The second is
>> to
>> create a new font with the new glyph.
> 
> Is it worth it?  I mean, that would be the biggest code duplication i've
> ever imagined - to have two fonts that differ with one glyph only!
> 

Well, actually, I wouldn't have it be a new font.  I'd have it be a
different version of the Feta font.  AFAICS, the majority has signed off on
this change to the font.  For those who don't want to use the new version of
the font, they can use the old version of the font.

>> Absent the new architecture, my recommendation is to wait on this patch
>> until 2.16 is out, and then apply the patch *without* the override
>> capability to 2.17.
> 
> (obviously) I don't like this solution because it makes my work lie on a
> shelf for a few months and do nothing but collect dust.

This proposal was based on Graham's assertion that 2.16 is 10 days away from
release, so your new clef would be 10 days away from being in 2.17.  If this
doesn't happen, I might change my mind.

And I'll take a look at the font switching capability.

> 
> Can we accept the style override as a temporary solution?  Sooner or later
> we'll implement font changing architecture and we'll then move to the more
> elegant solution.  We can set ourselves a deadline: with 2.18 the Clef
> #'style = #old override will be dropped regardless of whether we'll have
> font changing architecture or not.  How do you like it?


In the past, I would have been in favor.  Having seen what happened with
\chordGlissando, I am not in favor.

When you add the #'style =  #'old to the syntax, you'll have to remove it
shortly thereafter.  It makes a horrendous mess for convert-ly.

I'm pretty much solidly in favor of doing it right, rather than doing it
quickly.

If we need a shorter-term solution, and having had Graham take back his
Critical Regression brain fart, I'd say we go ahead and push the changes,
and then James will either have to use the current version, or maintain a
patch to the font.

Thanks,

Carl 




reply via email to

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