Re: [Patch] font-family

[Juergen Reuter]

On Wed, 14 Aug 2002, Han-Wen Nienhuys wrote:

> address@hidden writes:
> > If this is happens in a single instance, I could let it go, but now
> > you're putting this all over the code, in vital parts (eg. note
> > heads.)  I want to suggest the following approach.
> >
> >
> > Foo::brew_molecule
> > {
> >     return single_glyph_from_font
> > }
> >
> >
> > single_glyph_from_font (Grob *me)
> > {
> >     SCM proc = me->get_grob_property("find-font-symbol-procedure");
> >
> >
> > }
> >
>

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.

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.

> (continuing)
>
> On 2nd thought, I can't easily think of a general way to handle this,
> so I propose that the find-symbol-functions are changed to be a
> drop-in substitute for brew_molecule() callbacks. They are coded in
> Scheme, using tables like the code you submitted, and support for
> style properties is removed from the C++ ones.

In general, the complexity of the brew_molecule() functions does not get
smaller when using symbols from the ancient font.  In other words: *if* we
are going to implement the functionality of brew_molecule() as pure scheme
code, then we should do it for *all* styles, including the "default"
style (which could turn out to become quite a big project).  Otherwise,
the integrity of the ancient font will be lost due to certain features
that are then available only for the C++-coded "default" style case and
can not applied when using characters of the ancient font.

Similarly, functions such as note-head-style->attachment-coordinates (in
scm/outputlib.scm) will be disintegrated: depending on style, you call
part of this function directly from C++, the remaining functionality from
within a scheme function.  This does not sound nice.

>
> For some grobs (notehead, rest, mmrest), additional stuff must be
> done.

Yes.  That is what I just wanted to express with the term "big project".

> ...
> For using these definitions, a macro should be defined, i.e.
>
> ...

Such things can be done even more elegant by defining a new, dedicated
context, as shown in input/test/mensural-ligatures.ly (especially if
engravers have to be added to / removed from a *single* context, which is,
admittedly, not the case in your example, though).

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

> ...
> I can't tell how this would impact
> shaped noteheads (ie. cross/circle/etc)?

Should have roughly the same impact as on any ancient font character,
regardless in which .mf it is actually defined.

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

I have to further think about this.  Maybe your first thought was not that
bad; or maybe the scheme code can somehow be integrated into the font
character lookup code.

Greetings,
Juergen