[tex-k] mktexpk broken, pdftex PK flaw

[Hartmut Henkel]

Hi,

2 problems: First it seems that the current mktexpk is broken, at least
here (linux sarge, i686). It doesn't work on fonts other than 600 dpi. I
use thie TL05 version:

$Id: mktexpk,v 1.34 2005/06/21 10:49:10 olaf Exp $

My teTeX/share/texmf-config/web2c/mktex.cnf looks quite normal:

: ${MT_FEATURES=appendonlydir:varfonts}
: ${MODE=ljfzzz}
: ${BDPI=1200}

It's setup _not_ to 600 dpi. Now a simple call like

$ mktexpk cmr10

should work, no arguments needed, as mktexpk should know them from
mktex.cnf! But when i call this line, i get:

mktexpk: Running mf-nowin -progname=mf \mode:=ljfzzz; mag:=1.0;
nonstopmode; input cmr10
...
Font metrics written on cmr10.tfm.
Output written on cmr10.1200gf (128 characters, 46148 bytes).
Transcript written on cmr10.log.
mktexpk: `mf-nowin -progname=mf \mode:=ljfzzz; mag:=1.0; nonstopmode;
input cmr10' failed to make cmr10.600pk.

It knows about "ljfzzz" ok. But it tried to produce a 600 dpi font!
Within the mktexpk code the 600 dpi come into play after the call of
$MT_MKTEX_OPT, which is:

/usr/local/teTeX/share/texmf/web2c/mktex.opt

Somehow the environment is not set correctly by mktex.opt to the values
given by mktex.cnf.

Can anybody confirm this weird problem? (I have no clean solution yet.)


Second problem: In the past there were several e-mails complaining that
during a pdftex run, mktexpk is trying to make a weird 72 dpi font, when
the font PFB was not mentioned in the map file --- even when the right
PK resolution and mode are given in mktex.cnf! This has always been
attributed to a mapfile problem and then "solved" by a mapfile so that
in fact Type1 fonts were used. But the problem persists with PK fonts,
which should also run ok.

The reason for this flaw is, that pdftex _always_ communicates the
pdfpkresolution to kpse_init_prog(). Now, if pdfpkresolution is _not_
set anywhere, e. g. also not in pdftexconfig.tex (when a TeX environment
does not use this file), then pdfpkresolution defaults to 0 dpi, which
gets clipped to 72 dpi by pdftex, and then the call to kpse_init_prog()
is done with the 72 dpi. So pdftex _always_ overwrites the PK resolution
setting from mktexmf.cnf.

The solution was here to add always a correct pdfpkresolution to the
pdftexconfig.tex. People without this setting are lost, even with a
perfect default environment by mktex.cnf.

I believe it would be much better if without pdfpkresolution setting
kpse_init_prog() would ignore the value from pdftex, using the default
values from mktex.cnf. This can be done by a tiny patch in pdftex, e. g.
so that it gives either unclipped 0 dpi to kpse_init_prog(), or the
usual value between 72 dpi and 2400 dpi, if \pdfpkresolution has in fact
been set to something != 0 dpi. And if kpse_init_prog() gets 0 dpi as an
argument, it simply ignores it, so that the environment is not
overwritten. This would be similar to the check that kpse_init_prog()
already does for the "mode" setting.

Regards, Hartmut