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

[lilypond]

Updates:
        Labels: -Patch-review Patch-needs_work

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

2011/7/26 Trevor Daniels <address@hidden>
> The G clef font was changed 18 months or so ago by
> Carl without all this fuss.  There was discussion
> about the precise shape and a majority eventually
> emerged in favour of one shape.  The new font was
> then pushed, replacing the old.  Simple.  Easy
> Efficient.

> This time we have a clear majority in favour of the
> new font so why can you not just push it and let us
> all get on with life and other LilyPond issues?

Hmm, sorry for that...  My LilyPond experience got me used to patches being  
discussed and revised for weeks, so i don't feel the urge to close things.


2011/7/26  Comment #29 on issue 1752 by address@hidden:
> > > Today, if I wanted to, I could   \set Staff.clefGlyph =
> > > #"clefs.petrucci.g"

> > However, i was unable to apply this override to a change clef - how it's
> > done?

> % Given your patched .mf the first line below selects the old clef,
> % (and by renaming to 'G_old_change' I can compare the clef-change sizes  
> as
> well)

You mean that i should change mf glyph name from G_change_old to  
G_old_change (i.e. line 688 of feta-clefs  
http://codereview.appspot.com/4664070/diff/8001/mf/feta-clefs.mf#newcode688)?
...hmm, i did this but it doesn't seem to work.  I mean, this

\new Staff {
  a'\breve \clef G g'
}
\new Staff {
  \set Staff.clefGlyph = #"clefs.G_old"
  a'\breve \clef G g'
}

should print new clefs in the top line, and old clefs in the bottom line.   
but only regular clef in the bottom line has the old shape - change clef in  
the bottom line has new shape.  See attached.

> % I think Janek polished some rough edges in the clef so that
> % the new shape fits better with the rest of the the feta font

Thanks!


2011/7/26 Graham Percival <address@hidden>:
> On Mon, Jul 25, 2011 at 04:36:47PM -0600, Carl Sorensen wrote:
> > On 7/24/11 5:43 PM, "address@hidden" <address@hidden>
> > wrote:

> > > (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.

Oops, i see that i missed Carl's e-mail!  And i don't see it in the tracker  
issue comments.  Carl, could you forward it to me?
Well, 10 days from being in 2.17 is not that bad... but as Graham pointed  
out, it is quite uncertain.  Also, we don't have any idea when 2.18 will be  
available (since i'm ofc interested in having it in stable release :))

> > 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.

> I think this is the best solution as well.  It might be nice to
> add a bit more documentation about how somebody who really
> disliked the new font could go about replacing it, but we've never
> viewed documentation as holding back programming work in the past.

One thing seems clear for me: lets push new clef and discuss whether (and  
how) we want old clef included separately.
I'll revise Rietveld issue today.


2011/7/26 Graham Percival <address@hidden>:
> IMO [Neil's suggestion] mixes "musical meaning" with "graphical output"  
> too much.
> I would prefer to use the \commands to indicate musical meaning,
> and \override to alter the graphical output for a specific musical
> meaning.

+1, very good point.

cheers,
Janek

Attachments:
        clef-demo.pdf  19.6 KB