Re: Using \lookup to extract glyphs

[Werner LEMBERG]

[This is a rather long email with a lot of technical details, covering
 much more than just \lookup.  I spent almost two days with writing
 due to the necessary research in the lilypond sources since I'm not
 very acquainted with those tricky details.  If you are interested in
 lilypond's font handling details, please read it completely :-)]

> AFAICS the only fonts immediately available to \lookup which are not
> more easily accessible via \musicglyph are the myriad of braces of
> different sizes.

Correct.

> The Internal Reference suggests that font-encoding may be set to
> fetaMusic, fetaNumber, TeX-text, TeX-math, fetaBraces, fetaDynamic,
> but the glyphs in fetaMusic, fetaNumber and fetaDynamic are all
> available via \musicglyph, and the TeX fonts don't seem to be
> distributed with LilyPond and are not available by default on
> Windows.

Today, only `fetaMusic', `fetaBraces', `fetaNumber', and `fetaDynamic'
(the last one is exactly the same as `fetaNumber', BTW) are valid
values for `font-encoding'.  Other values have no effect at all and
get silently ignored.

Note that the `fetaNumber' encoding is handled inconveniently:
lilypond currently constructs a font name like `feta-alphabet20' which
is then loaded via the Pango/fontconfig mechanism.  This has two
drawbacks:

  (1) Inspite of the fact that all glyphs accessed by the `fetaNumber'
      encoding are in the Emmentaler fonts, a separate Type 1 font is
      loaded (feta-alphabetXX.pfb; lilypond registers all of its `otf'
      and `type1' fonts to the fontconfig mechanism during start-up).
      Doing so increases the size of the final PDF, and we want to get
      rid of the PFBs anyway since they are redundant.

  (2) \lookup doesn't work with `fetaNumber': It only works for fonts
      loaded by `ly:font-load'; as explained in a previous mail, this
      means the Emmentaler and Aybabtu fonts, but not feta-alphabetXX.

[As a corollary of the above I think that functions like
 `add-cmr-fonts', `add-cork-lm-fonts', and `add-ec-fonts' in
 `fonts.scm' can be removed.  Similarly, the no longer needed kpathsea
 stuff should be really removed everywhere.  I can do this if you
 agree.]

A possible fix would be to map the `fetaNumber' encoding to the
Emmentaler font so that Pango/fontconfig handles text strings if
`fetaNumber' encoding is selected.  Here's a patch which does this:

  --- font.scm.old        2008-10-30 00:33:51.000000000 +0100
  +++ font.scm    2008-11-27 08:34:29.000000000 +0100
  @@ -140,8 +140,7 @@
         (list->vector
          (map (lambda (tup)
                (cons (ly:pt (cdr tup))
  -                   (format "feta-alphabet~a ~a"
  -                           (car tup)
  +                   (format "Emmentaler ~a"
                              (ly:pt (cdr tup)))))
              '((11 . 11.22)
                (13 . 12.60)

Unfortunately, this effectively disables the size mechanism of the
Emmentaler fonts; the above patch makes lilypond always use
emmentaler-11.otf for `fetaNumber'.  Reason of the problem is that
fontconfig controls the various design sizes of the Emmentaler fonts
with the `style' property; if you list all fonts with lilypond's
`-dshow-available-fonts' option, you see things like this:

  family Emmentaler
   Emmentaler:style=14
  family Emmentaler
   Emmentaler:style=16

and lilypond has no `font-style' property yet.  To add it, extensions
to both the lilypond binary (cf. `properties_to_pango_description' in
pango-select.cc) and to font.scm (cf. `default-qualifier-order') are
necessary.  Alas, the GOOPS stuff in font.scm is Byzantine to me :-(

Han-Wen, can you afford some time to implement this?  Or do you see a
better solution?


                              *   *   *


Another observation which is probably not obvious: Text strings are
*always* handled by the Pango interface.  In other words, if you say

  \markup {
    \override #'(font-encoding . fetaMusic)
    "foo"
  }

you get no output: The fonts loaded for `fetaMusic' and `fetaBraces'
encoding are not using the Pango interface.


    Werner