Re: LilyPond 2.1.31

[Mats Bengtsson]

Han-Wen Nienhuys wrote:
> address@hidden writes:
>
> > Han-Wen Nienhuys wrote:
> >
> > > The 'Pond numero 31 has been slung onto the net.
> > >
> > > Bugs fixed include the alignment of bass figures and spurious dynamic
> > > warnings in MIDI. New attractions include:
> > >
> > >   * The code for font selection has been rewritten. In addition to
> > >     existing font selection properties, the property `font-encoding'
> > >     has been added, which makes the switch between normal  `text' and
> > >     other encodings like `braces',  `music' and `math'.
> > >
> > > (the new code runs in Scheme, not C++. I would be interested to hear
> > > whether .31 is measurably slower than .30)
> >
> > Can this font-encoding feature also be used to support T1 and other
> > font encodings in LaTeX, so we can handle a more complete set of
> > characters?
>
>
> Yes - but we haven't looked deeply yet, but TeX encoding's require
> another layer of translation, since input files will be in
> latinX rather than a TeX encoding (or are they the same?).

The font selection scheme in LaTeX involves two translations:

\usepackage[latin1]{inputenc} gives a translation from the character
set in the input file to a TeX representation
('ä' -> '\"a', 'ç' -> '\c c', e.g.)

\usepackage[T1]{fontenc}
a translation from the TeX representation to the encoding used in the
font.

For latin1, it happens to be that most characters have the same
number in latin1 as in the T1 font encoding, which is why LilyPond
gives the correct characters in the output today. However, some
characters fail and if you change to other character sets the problems
can get worse. In LilyPond, it's probably overkill to invent an internal
representation and we could have one translation table for each
combination of input incoding and font encoding. This should be enough
to support all languages supported in the ISO 8859-x series. A much
larger step would be to support Unicode, to cover also east asian
languages, for example.

    /Mats