FYI pango/font status

[Han-Wen Nienhuys]

Hi there,

followers of the CVS commit list might have noticed that
Pango/FontConfig integration is proceeding. The last status is that
--format=ps now produces credible results in the PS output, and that
the dimensions of bounding boxes are computed correctly. The current
TODO list for the pango integration is:

* To provide backend routines for Pango_font::text_stencil, which is
  suitable for the SVG and GNOME backends.
 
  My current idea is to wrap PangoFontDescription as SCM and dump that
  into the backend. I hope for some input by Jan on this, since I
  guess that the GNOME backend already has Pango bindings.

* To call latex automatically for the texstr backend, and to collect
  _all_ strings in a single file (right now, a .texstr file is written
  for every toplevel \book).

* Remove all support code for encoding within LilyPond. LilyPond reads
  UTF-8 (which is a superset of latin1). Encoding is either handled by
  (La)TeX, or by Pango. This means that

    \encoding

  will disappear, as will the inputencoding field in \layout{}

* We still could have LilyPond call iconv to convert other encodings
  to UTF-8, but my feeling is that this does not really add to the
  functionality. How is UTF8 support for other (non-emacs) editors,
  and what encodings besides latin1 are currently used for .ly files?

* How do we deal with kerning in Pango? AFAIK, Pango does not read
  AFM/TFM files, so how can it compute kernings?

Integration of Pango has brought a new problem: there are now two
disparate ways of selecting fonts and font styles in LilyPond. The
first one is the pre-2.4, which uses

  font-family
  font-shape
  font-series
  etc.

the second one is the FontConfig (FC) mechanism, which uses

  font-family
  font-weight
  font-variant
  etc.

in addition, there are plenty of rules available to customize
FC, which work in GUI apps (so you can select the "Sans"
font).

I believe that we should focus on FC: FC is well-supported, external
code, which offers more functionality and does not have to be
maintained by us. This implies that we should find a way to shoehorn
TeX fonts (and with that, kpathsea file searching) onto FC

My ideas are as follows:

* all font files should either be loaded through FC or by Lily
  directly. Lily does not link to kpathsea anymore.

* Question: can we load TFM files through FC?  We still need to read
  TFM files for a rough estimate of text extents to base the texstr
  output on.

* the CMR fonts do not have characteristics defined; the type1 fonts
  just list fontname = "cmbx12".  We should have a separate package,
  which collects all TeX type1 fonts (using kpathsea), defines
  style/weight/etc. characteristics and generates appropriate FC cache
  files.

* How do we deal with design sizes? We can kludge them onto
  font-weight and/or font-stretch. It would be best if a feature was
  added to FC, where we can specify design sizes.

  Another option is to make FC return font-sets, and make sure that
  all related design sizes are returned as a single fontset
  eg. containing cmr6 to cmr17. Then LilyPond could try to determine
  design sizes, and select which font to use.

* For the TeX backend, we need to have a mapping from font-description
  (family, weight, etc.) to file names. Should not be too hard.

* We should add special font-family specifications for the brace and
  music fonts. Those should be selected through font-config as well.

* For music, the default font (on my system: Sans) is not suitable for
  music. LilyPond should insert aliases into FC to make sure that we
  get proper fonts. We should also select sensible defaults from the
  PS standard fonts for texts.

* Font selection should be done through FC directly; this means that
  is used twice, both directly and through Pango.  It's not yet clear
  to me whether we need extra code to handle this duplicity.

-- 

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