[tex-live] dvipdf on Debian etch does not create fonts

[Ralf Stubner]

On Tue, Nov 27, 2007 at 00:26 +0100, Zdenek Wagner wrote:
> 2007/11/26, Ralf Stubner <ralf.stubner at web.de>:
> > No, the -Ppdf option loads config.pdf. This file not only loads font
> > maps such that Type1 fonts are used (that's the default behaviour of
> > dvips since teTeX 2 IIRC), but it also sets a very high value for the
> > resolution to be used:
> >
> > ,----[ config.pdf ]
> > | % Default resolution. Attempt to make `resolution independent'.
> > | % Resolution set to 8000dpi (could be as high as 10000).
> > |
> > | D 8000
> > `----
> >
> > This does make sense, if only Type1 fonts are used. However,
> 
> No, this has nothing to do with fonts.

It has. Using, eg, OT1 encoded condrete fonts, for which I have no
Type 1 version installed, I get:

$ dvips -Ppdf pdf-mf.dvi 
This is dvips(k) 5.96.1 Copyright 2007 Radical Eye Software (www.radicaleye.com)
' TeX output 2007.11.27:2040' -> pdf-mf.ps
kpathsea: Running mktexpk --mfmode ljfour --bdpi 8000 --mag 1+0/(2*4000) --dpi 8000 ccr10
mktexpk: Mismatched mode ljfour and resolution 8000; ignoring mode.
mktexpk: Running mf-nowin -progname=mf \mode:=dpdfezzz; mag:=1+0/(2*4000); nonstopmode; input ccr10
This is METAFONT, Version 2.71828 (Web2C 7.5.6)

(/usr/share/texmf-texlive/fonts/source/public/concrete/ccr10.mf
(/usr/share/texmf-texlive/fonts/source/public/cm/cmbase.mf)
(/usr/share/texmf-texlive/fonts/source/public/cm/roman.mf
(/usr/share/texmf-texlive/fonts/source/public/cm/romanu.mf
The letter A [65]
The letter B [66]
The letter C [67]
The letter D [68]
The letter E [69]
[...]
Font metrics written on ccr10.tfm.
Output written on ccr10.8000gf (128 characters, 527808 bytes).
Transcript written on ccr10.log.
mktexpk: /home/rfstubne/.texmf-var/fonts/pk/dpdfezzz/public/concrete/ccr10.8000pk: successfully generated.
</home/rfstubne/.texmf-var/fonts/pk/dpdfezzz/public/concrete/ccr10.8000pk>
</usr/share/texmf-texlive/dvips/base/tex.pro>
</etc/texmf/dvips/config/alt-rule.pro>. [1] 
$

> Due to frequent bugs in
> floating point arithmetics in various PS RIPs dvips converts all
> dimensions to integer pixels according to resolution. Letterspacing
> corrections and kernings accumulate and are inserted when they achieve
> integer number of pixels. Take any document typeset with Type 1 font,
> decrease the resolution (e.g. by the command line switch) to a very
> low value, say 50, process it again by dvips and you will see that the
> letterspacing will come out very ugly. I makes no sense to rasterize
> bitmap fonts at such a high resolution. Anyway, metafont will most
> likely report overflow with most fonts.

As I had written, it was this numeric overflow that I had expected. To
my surprise I haven't found a font where it does occur, though. I have
had a look at error reports concerning the -Ppdf option (they used to
be quite common!), and the problem always was that there was no
matching mode definition for 8000 BDPI. However, meanwhile somebody
has added such a definition to modes.mf. Does anybody know when this
happend? Not having such an entry might explain the OP's problems.

cheerio
ralf