dvips problems ?

[Fabrice Popineau]

* Sebastian Rahtz <sebasti...@computing-services.oxford.ac.uk> writes:

Fabrice Popineau writes:
Fabrice> D:\maufoy\hdr>dvips hdrtl -o
Fabrice> This is dvips(k) 5.86d Copyright 1999 Radical Eye Software (www.radicaleye.com)
Fabrice> 'TeX output 2000.03.29:1015' -> hdrtl.ps
Fabrice> dvips: Font Garamond used in file figures/fig1bis.eps is not in the mapping file.
Fabrice> dvips: Font Arial-ItalicMT used in file figures/figkuk.eps is not in the mapping file.
Fabrice> dvips: ! Couldn't find header file ma1r8a.pfb

Sebastian> oh, I hate this business. dvips should stop looking
Sebastian> inside included files like this.

I'm a bit afraid trying to fix (?) this, but I guess it is around line 429 of
finclude.c where figures are scanned for ps font usage :

} else {
f = search(figpath, filename, READ) ;
}
if (f) {
fc_state = 0;
check_atend = 0;
while (fgets(p,500,f) && p[0]=='%' &&
(p[1]=='!' || p[1]=='%' || p[1]=='*')) {
if (strncmp(p, "%*Font:", 7) == 0) {
scan1fontcomment(p+7);
} else if (strncmp(p, "%%VMusage:", 9) == 0) {
truecost += scanvm(p+10) ;
trueknown = 1 ;
}
scanfontusage(p,filename);
}

Maybe someone here can comment about the benefits/drawbacks in
removing the call to scanfontusage ?

Basically, the problem is that you can have figures with embedded
(partial !) font, the font is listed in psfonts.map (for
completeness) and you don't have actually the .pfb. Dvips will stop
printing, whereas it could have print the job.

Fabrice

[Tomas G. Rokicki]

Yeah, I've never been happy with what dvips does with included EPSF
files myself. The problem as I understand it:

1. If a document uses a particular PostScript font, it needs to have
DSC comments indicating this and whether the font is included in
the document or must be in the printer.
2. These headers *must* be in the header section of the outer PS
file; leaving a RequiredFont or RequiredResource in a nested
file won't work.

If you violate (1), your document won't print on a lot of devices with
spoolers that manage the fonts for the device. (Of course, these days,
it's common that devices manage the fonts themselves, but still.)

So if we *need* to satisfy (1), then (2) means that we need to scan all
enclosed files and uplevel the required resources.

Then there's the second problem. If an enclosed EPSF file uses a font,
say, /HoundBaskerville, and the outer file also uses that same font,
then they can fight over this font name. I'm not sure that dvips
actually does the correct thing here and it's something I need to
investigate . . .

But let it be said that before I started scanning EPSF files for the
required fonts, all sorts of things used to break when printing on
some systems.

The reason I've never been comfortable with all of this is, the whole
notion of enclosing a DSC file into another is a complex, fragile
mess, and one for which I had hoped Adobe (who defined the whole thing)
would provide a standard implementation for so all the app writers
didn't get it wrong. To my knowledge, this has not happened.

Now, perhaps dvips shouldn't emit a fatal error and die when it can't
find a font that an EPS file says it needs. Perhaps a warning, and
proceeding along is the correct thing to do.

Does anyone have any feelings about this? I should revisit the Adobe
site and see what the state of the art is (it has been years since I
considered this problem).

The interesting thing is, since the DocumentRequiredFonts is pretty
global, if an EPSF file needs a font, since there is no way to tell
what characters an EPSF file will use from that font, you have to
send the entire font---no way to do partial downloading. I don't
remember if I enforced this in dvips or not.

-tom