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: Han-Wen Nienhuys
Subject: Re: [Patch] Bugfix (Was: Re: Still missing some ancient clefs)
Date: Thu, 29 Aug 2002 21:27:42 +0200

address@hidden writes:
> > 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 '().

Are you sure that a sane notehead font/glyph-description comes out of
the scheme function?  The dumps you showed look like the result of
using an empty (nonexistant) glyph.

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

I'm not sure what is the best way to represent the font in
paper20-style-sheet-alist (font.scm), and what to do with indexing by
number (should we insert the fonts at multiples of 256, or do we
concatenate all of the font indices?).  Building a hash-table inside
font-metric shouldn't be a problem.


-- 

Han-Wen Nienhuys   |   address@hidden    | http://www.cs.uu.nl/~hanwen/





reply via email to

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