Han-Wen Nienhuys wrote:
[EMAIL PROTECTED] 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
_______________________________________________ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
