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: lilypond
Subject: Re: Issue 1752 in lilypond: redesigning G clef in our Feta font
Date: Sun, 24 Jul 2011 23:43:02 +0000


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

2011/7/24  n.puttock:
if we must have the option of switching between old & new, I
think a parser-clef.scm entry would make more sense.

I'm not sure, but implementing this shouldn't be a problem.


2011/7/24  percival.music.ca:

The "critical regression" thing was a complete brain fart from me and should
be scornfully ignored.

Whew!
:)

However, I am aghast that the "font switching architecture" is going
nowhere.  As far as I understand it,
  1. we can switch to a different OTF font.  (aka "gonville")

Everything that i see on this topic is here
http://lilypond.org/doc/v2.14/Documentation/notation/replacing-the-notation-font.html
and it seems like an ugly hack... I wouldn't call that "we support choosing different fonts".


2011/7/24  Carl.D.Sorensen:
Graham wants to avoid
the new clef since it would be a Critical Regression.

Now THIS is the best quote i've heard in a while!  Perfect wording, Carl! :D

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!

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.

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?




reply via email to

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