LilyPond 1.3.150-1 patch from Debian

[Anthony Fok]

Hello Jan and Han-Wen,

Attached is the Debian diff.  :-)
Please do look through it before applying it, because I made changes to
lily/kpath.cc and Documentation/user/GNUmakefile that you may want to
double check.

+++ lilypond-1.3.150/lily/kpath.cc
+++ lilypond-1.3.150/debian/changelog
+++ lilypond-1.3.150/debian/control
+++ lilypond-1.3.150/debian/copyright
+++ lilypond-1.3.150/debian/postinst
+++ lilypond-1.3.150/debian/rules
+++ lilypond-1.3.150/debian/lilypond1.3.copyright
+++ lilypond-1.3.150/stepmake/stepmake/toplevel-targets.make
+++ lilypond-1.3.150/Documentation/user/GNUmakefile

In particular, regarding the following comment in kpath.cc:

    Remove the setting for TFMFONTS if we have kpathsea, because
    kpathsea can find TFM fonts anyway.

    If we don't lily will want to make tfms for cmr fonts, even if
    there is a :: entry in the TFMFONTS path.

I think it is not quite accurate.  :-)
I think we can keep TFMFONTS, and no, lilypond won't make TFMs for cmr
fonts if we add the colon at the right place, hence the change:

    char * mypath = kpse_expand ((my_tfm + ":").ch_C ());
                                 ^^^^^^^^^^^^^^

Also, you may hate me for this, but I decided to add those "#ifdef DEBIAN"
stuff too, because "$VARTEXFONTS/tfm/public/lilypond" is currently the
standard in web2c.  By that, I mean the feta font is listed in
/usr/share/texmf/fontname/special.map:

        @c @mapfile{
        @c   email = "address@hidden",
        @c   date = "30 May 1999",
        @c   url = "http://tug.org/fontname/special.map";,
        @c   supported = "yes",
        @c   docstring = "Abbreviations for nonstandard TeX font names."
        @c }
        ...
        ...
        feta            public          lilypond

So, at least for the Debian package, I would rather let teTeX do its job
(it knows where to put the fonts properly using to special.map)
than using --destdir to force the TFMs, including non-feta fonts, to go
into $VARTEXFONTS/tfm/lilypond/<version>.  Besides, since feta*.tfm
are already installed to, say, /usr/share/texmf/fonts/tfm/public/lilypond,
lilypond should never need to regenerate feta*.tfm under normal
circumstances anyhow.

I have tested this on Debian with -DDEBIAN, and it seems to work as
expected.  Please do test without -DDEBIAN on your favourite platform
to make sure the "add the colon" trick works too.  :-)

Oh, one more thing.  There seems to be a small bug in the feta?? fonts
in 1.3.150.  They are not truly device-independent, and it gave checksum
errors when, for example, the TFM is generated in MODE=ljfour
and the PK in MODE=epstylus:

$ xdvi l-fake.dvi
Checksum mismatch (dvi = 3022688161, pk = 3561820577) in font file
        /var/spool/texmf/pk/epstylus/public/lilypond/feta16.360pk
Checksum mismatch (dvi = 2276510827, pk = 3220606057) in font file
        /var/spool/texmf/pk/epstylus/public/lilypond/feta20.360pk

As mentioned in metafont-for-beginners.tex:

    Incidentally, properly constructed {\sc tfm} files are
    device-independent, so running \MF{} with different modes normally
    produces the identical {\sc tfm}.
    % This explanation might want a different place...
    Dimensions in {\sc tfm}~files are specified to~\MF{} in device
    independent `sharped' dimensions (commonly suffixed by \#), where
    a~value of~1 corresponds to the dimension of {\tt 1pt} (typographical
    point).  Most of \MF{}'s calculations are done with (resolution and
    device dependent) pixels as units.  Care must be taken by font
    designers to {\em always\/} calculate unsharped dimensions from sharped
    ones, and never the other way round, so as to keep roundoff errors or
    similar effects from influencing the {\sc tfm} files to depend on
    resolution or device.  Although type quality will be influenced only in
    minuscule ways, this is one of the more common reasons for checksum
    errors reported by printer drivers.
    Note that the only way to be sure that a TFM file is device-independent
    is to create the font in different modes and compare the resulting
    TFM's, perhaps using {\sf tftopl}.

Hehe, I am sure you know a lot more about Metafont than I do.  So, yes,
please to fix it before 1.4 is out.  :-)

Thanks,

Anthony

-- 
Anthony Fok Tung-Ling                Civil and Environmental Engineering
address@hidden, address@hidden    University of Alberta, Canada
   Debian GNU/Linux Chinese Project -- http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/

lilypond_1.3.150-1.diff
Description: Text document