Re: Questions about mapfile handling
At 00:12 16/11/2003, Hartmut Henkel wrote:
Disabling this mechanism seems to be rather easy, as it is triggered only from one place. Would a global \pdfxobjkeepfonts (default 0) have the right name?
sounds ok to me
indeed, esp the slant is a problem (but maybe even pseudo small cap files):
SlantFont and ExtendFont we have. But how can one currently see from an entry in the map file (like " SCFont "), that it's a pseudo small-cap file?
this is indeed a problem, (and one reason more for me to use a different naming scheme than kb) fortunately those pseudo caps are seldom used Hans
Hi, there has been a change from pdftex as in teTeX-2.0.2 to pdftex-1.11b.tar.gz, in that in mapfile.c there is now: if (strcmp(buf, nontfm) == 0) fm_ptr->tfm_name = xstrdup(nontfm); which was still in teTeX-2.0.2: if (strcmp(buf, nontfm) == 0) fm_ptr->tfm_name = nontfm; As a consequence, in function lookup_fontmap(), it seems that now the comparison if (p->tfm_name == nontfm) p->tfm_num = newnullfont(); will never succeed (and there are a few more places), as xstrdup(nontfm) returns a pointer _not_ pointing to the constant "<nontfm>" string. So there seems to be something probably wrong; which has no influence at all as long as nobody uses the undocumented (?) "<nontfm>" TFM entry in mapfiles. Has anybody used this obscure <nontfm>, and what is it good for? Regards, Hartmut
On 2003-11-23 21:56:06 +0100, Hartmut Henkel wrote:
Hi, there has been a change from pdftex as in teTeX-2.0.2 to pdftex-1.11b.tar.gz, in that in mapfile.c there is now:
if (strcmp(buf, nontfm) == 0) fm_ptr->tfm_name = xstrdup(nontfm);
which was still in teTeX-2.0.2:
if (strcmp(buf, nontfm) == 0) fm_ptr->tfm_name = nontfm;
Introduced by me as gcc issues a warning about incompatible comparisons (or something to that effect). Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
Hi, it seems that pdftex and pdfetex currently don't automatically produce pk fonts, when missing. Instead a warning is produced. Walter Schmidt and Frank Küster commented on this in a recent post in de.comp.text.tex ("Re: pdflatex-Fehler mit tipa", Date: Tue Dec 09 18:17:10 CET 2003). The reason seems to be, that in file texk/kpathsea/tex-make.c, function kpse_make_tex() the parameter spec.program_enabled_p always is zero, so that the maketex() function required for pk generation is never called. I don't know whether this is wanted by design. And nowadays in most cases Type 1 fonts are used. But the automatic generation of pk files could be activated by a tiny change in file web2c/lib/texmfmp.c. Here is the patch; the line is borrowed from texk/dvipsk/dvips.c: --- /usr/local/src/tex/pdftex-1.11b-orig/src/texk/web2c/lib/texmfmp.c Mon Sep 15 17:23:29 2003 +++ texmfmp.c Thu Dec 11 00:40:02 2003 @@ -248,6 +248,9 @@ kpse_src_compile); #endif /* MP */ #ifdef TeX +#if defined(pdfTeX) || defined (pdfeTeX) +kpse_set_program_enabled (kpse_pk_format, MAKE_TEX_PK_BY_DEFAULT, kpse_src_compile); +#endif #if defined(Omega) || defined (eOmega) kpse_set_program_enabled (kpse_ocp_format, MAKE_OMEGA_OCP_BY_DEFAULT, kpse_src_compile); Regards, Hartmut
On Thu, 11 Dec 2003, Hartmut Henkel wrote:
it seems that pdftex and pdfetex currently don't automatically produce pk fonts, when missing.
Oops, this can be activated easily in texmf.cnf: MKTEXPK = 1 (which was 0). So no patch required. Sorry for the noise. Greetings, Hartmut
participants (3)
-
Hans Hagen -
Hartmut Henkel -
Martin Schröder