lilypond-devel
[Top][All Lists]
Advanced

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

Re: [Patch] font-family


From: Han-Wen Nienhuys
Subject: Re: [Patch] font-family
Date: Wed, 14 Aug 2002 20:45:31 +0200

address@hidden writes:
> 
> Well, I think I got the general idea, but I do not fully understand why
> this should me much faster, unless me->get_grob_property("...") is much
> faster than having scheme to search for a function given by its name.

The Scheme evaluator of GUILE is quite slow.  For glue applications,
that is not much of a problem, but I don't think it is wise to move
critical code to Scheme. Lily is already very slow.

> Anyway, font_metric->find_by_name(font_char) also has to perform a
> string-to-whatever lookup, so why not, on the long term, somehow integrate
> the scheme code that I wrote with the code that looks up the font_char?
> That should save half of the font character related lookups.

I don't understand this. Can you explain this more clearly.  

> 
> > \ancientNotation is only needed once for every staff/score etc  using
> > special styles.
> 
> \ancientNotation is not at all needed, when you are using such a dedicated
> context.

indeed, but I am not sure about the uses of the all the different
styles.

> According to the current situation, you have two properties "style"
> and "font-family" which have almost always to be set pair-wise: if you
> change "style", chances are big that you also have to change
> "font-family", or the expected font character will not make it into your
> score.  Since all font character names are still unique, there is
> absolutely no need to set "font-family" manually.  This can and it should
> be done automatically.  I consider the current sitaution as a severe bug
> that really should be somehow fixed before releasing 1.6 (in the sense
> that the user should not have at all to care about "font-family", by
> whatever solution we can find).

Ok, so the real problem remains that we only have 256 entries for a
font. We should somehow comeup with a kind of virtual font mechanism:
have one "music" font that acts as if it has thousands of glyphs, but
in reality is composed of multiple ordinary fonts.

A new Font_metric derived class should be made? We should also use
such a mechanism for the braces, so that we see one big font for the
braces.


-- 

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





reply via email to

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