lilypond-devel
[Top][All Lists]
Advanced

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

Re: [Patch] Bugfix (Was: Re: Still missing some ancient clefs)


From: Juergen Reuter
Subject: Re: [Patch] Bugfix (Was: Re: Still missing some ancient clefs)
Date: Thu, 29 Aug 2002 21:00:25 +0200 (CEST)

On Thu, 29 Aug 2002, Han-Wen Nienhuys wrote:

> ...
> > > Do I understand correctly that this patch does a regex match for every
> > > note head in the default setting?
> >
> > No, last year, you explained that you want the default style be set to
> > 'default' rather than leaving it undefined (I think to avoid various
> > crashes, IIRC).  Consequently, this is exactly, what is currently done in
> > scm/grob-description.scm:
> >
> >     (NoteHead
> >      . (
> >     (style . default)
>
> Ah, I'm not being very consistent. -- Where can I find the mail where
> I said that? (time for some reflection :-)
>

I looked through the archive, but unfortunately I could not find it any
more.  If I remember correctly, it was when I had submitted some patch.
You replied that in scm/grob-description.scm, property style should be set
to 'default'.

> In general, the idea is to have undefined ( '() ) give save default
> behavior, but in some cases this leads to weird property names
> (noAutoBeaming) or weird code; in those cases the lesser bad thing is
> to have explicit defaults. I'm probably don't follow the ancient code
> close enough to understand what or where the issues are (sorry).
>

As far as I can see, there are no issues among the ancient code regarding
the default value.  But some other part of lily's code currently seems to
assume that this property is set to a value other than '().

> OK. I'll apply it then.
>

Thanks!

> > BTW., this bug is yet another symptom of the font-family problem.  We
> > *really* should do something about it, or it will hunt us forever!  I
> > think your recent suggestion to implement a virtual font with more than
> > 256 characters points into the right direction (and comes effectively
> > close to what I vaguely suggested half a year ago).
>
> I'm looking forward to receiving a patch, OTOH, this delves deeply
> into the core, so maybe I should try writing the code myself. Let me
> know when you start tackling it, otherwise we might do double work.
>

Yeah, sounds like if it affects quite a lot of files.  So, if you actually
would like to volunteer on this challenge, I will be the last one
preventing you from doing so. :-)

Of course, if this breaks ancient font code, I will try to contribute
patches.

I do not know the details of the current implementation and the tex/mf
internals, so I may be talking garbage.  Having this said, remember that
the name of each font character is unique (i.e. the name spaces of feta
and parmesan do not clash).  This means a single lookup in a single big
hashtable ( { character_name } -> { font, charcter_index } ) should
suffice, rather than trying one font after the other until a font family
with a character of the given name is found.

Greetings,
Juergen





reply via email to

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