lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Latin Modern and cm-super in Debian


From: Florent Rougon
Subject: Re: Latin Modern and cm-super in Debian
Date: Tue, 27 Apr 2004 16:54:43 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux)

[ Now, I'm subscribed to the list for the sake of this discussion in
  order to avoid delays due to moderation, but you may still Cc me for
  safety ]

Jan Nieuwenhuizen <address@hidden> wrote:

>>      I repeat: cm-super in Debian is only waiting for a maintainer
>
> (is it in wnpp?)

Er, it has been sitting there for 2 years and 74 days.

> You hinted in your package description that lmodern is `better', and

This is a fairly simplistic summary of what I wrote there. Better visual
quality in general, probably, but not as complete in some respects
(number of available sizes [which is a deliberate design choice of the
Latin Modern authors], families, they don't contain the same glyphs...).

> Werner indicated that development on lmodern is going faster than
> cm-super, combined with the fact that cm-super was not available in
> Debian, had me think that we maybe should wait for lmodern to really
> surpass cm-super before switching to one of those at all.

I fail to see the "switching" problem you seem to be concerned about. If
you don't install the lmodern package, you don't have the Latin Modern
fonts. If you install the lmodern package, just like with most other
(La)TeX packages, you only see a difference if you explicitly ask for it
in your documents (\usepackage{lmodern} in LaTeX). I understand this may
not be the case with a standard installation of cm-super[1], but please
don't use this argument against lmodern.

>>   2. I uploaded a package of the latest upstream release of the Latin
>>      Modern fonts here today:

[...]

> Ok, that's great, but it still means that LilyPond would depend on
> something th'ts currently not in Debian, which is not a good thing.

And for which I have absolutely no responsibility.

> The lmodern description says:
>    [..]
>    The Latin Modern fonts were generated using MetaType1,
>    [..]
>
> The 'bullshit' was referring to that sentence.
>
> Noone here has actually investigated it further, I think, but as I
> read it, Werner and Han-Wen reached consensus that fully automated
> generating of type1 from mf sources is most probably not what
> happened:

And is definitely not what I wrote in the lmodern package description.

>     Han-Wen:
>     Perhaps, but then the word "*generated* using
>     MetaType1" is not entirely accurate.
>
> So, now that you're taking part of this discussion, perhaps like to
> explain how they were made, exactly?  And in case the process indeed
> is not [fully] automatic, you may want to make the package's
> description less misleading.

Please point me to the place where the description says "automatic". I
am unable to find it. Really.

The fonts were generated with a somewhat complicated process (though
Han-Wen said he considered the META-Type1 approach "very simplistic" if
I am to believe [2]). This process uses the PFB and AFM files from CM
Type 1 to obtain META-Type1 code, which I think is for most parts of it,
very close to MetaPost code. This META-Type1 code was refined (read: not
fully automatically), some METAFONT code from the PL fonts (for some
accents) or CM fonts (C -> euro sign) was incorporated in it, etc.

More gory details can be found in [2] and [3]. For my package
description, I chose to include a short sentence quite similar to what
upstream considered appropriate for its README-file equivalent
(/usr/share/doc/lmodern/0info092.txt.gz). Here is what upstream wrote:

  The fonts were generated using METATYPE1---a METAPOST-based package
  for generating fonts in the PostScript Type 1 format
  (ftp://bop.eps.gda.pl/pub/metatype1/).

This is also very close to what can be read in the TeX FAQ[4].

> I agree that there's probably a world of nuances between `bullshit'
> and `not entirely accurate'.

Additionally, a Debian package description is supposed to be easy to
understand, even for someone that doesn't know the technicalities
surrounding the package, and relatively short. When "entirely accurate"
is impossible to achieve given these constraints, some other way has to
be chosen.


[1] With a standard installation of cm-super, if you ask dvips/pdftex to
    use Type 1 fonts when available, you will get the cm-super fonts if
    you compile LaTeX documents without specifying any particular font
    family (no \usepackage{times}, etc.) and using the T1 encoding. This
    is bad if the document is intended to be printed, as opposed to read
    on a screen, because the PK fonts in the appropriate resolution
    generated from the CM Type 1 fonts released by the AMS (i.e., those
    that would have been used in the same configuration without cm-super
    installed) would be much better than the cm-super Type 1 outlines.
    See [3] pp. 44-46 for a comparison between a cm-super M and the
    equivalent M from the CM fonts in Type 1 format released by the AMS.

[2] http://www.tug.org/tug2003/preprints/Jackowski/jackowski.pdf

[3] http://www.tug.org/tug2003/bulletin/highlights/slides/8_Jackowski.pdf

[4] http://www.tex.ac.uk/cgi-bin/texfaq2html?label=type1T1

-- 
Florent




reply via email to

[Prev in Thread] Current Thread [Next in Thread]