Note minimal input file and other files below.

My texlive-latex-base version is 2007.dfsg.1-4
My ghostscript version is 8.62.dfsg.1-3.1

I do: ps2epsi graphics.ps
to make graphics.epsi

Then I do: latex problem.tex
to make problem.dvi

Now, if I do: dvips problem.dvi
and look at the result with gv,
there are missing characters, as at http://imagebin.org/33420

But, if I do: dvips -j0 problem.dvi
and look at the result with gv,
everything is fine, as at http://imagebin.org/33421

Hi Mark,

thnaks for your report.

I cannot reproduce your problem here, but I have a suspicion where it
might come from. What is the output of the following commands:

kpsewhich --format='web2c files' updmap.cfg
egrep dvipsDownloadBase35  $(kpsewhich --format='web2c files' updmap.cfg)


I suspect that dvipsDownloadBase35 is set to true, which is not the
default value. But it can cause problems like the one your are
describing: Both the main document as well as the included image uses
one of the 35 PostScript base fonts (Times Roman in this case). Since
every PostScript interpreter is expected to have these fonts, they are
typically not included in PS files like your image. If, however, you
tell dvips to embed this font into the resulting PS files, it will
only download those glyphs, that are used in the DVI file. Not those
used in the image. But a PS interpreter rendering the resulting
document will only use the embedded partial version of Times Roman, so
that glyphs like P and S that are present in the image but not in the
DVI file are missing. The option -j0 tells dvips to download the
complete font, so that all glyphs are present even if they are not
used in the document.

As I said, dvipsDownloadBase35 is set to flase by default. If I am
right and you have set it to true, why did you do so?

cheerio
ralf

Ralf Stubner <ralf.stubner@web.de> writes:

You are correct. I did this a long time ago and completely forgot;
apologies for forgetting a way in which I had poked things away from
defaults.

I have a habit of having to submit documents to people who require me to
embed all fonts: for instance, papers for IEEE, and reports to the
National Science Foundation. How sensible that requirement of theirs is,
I'm not sure.

How /necessary/ it is I don't know; perhaps I can get away with just
sending them PDF and using ps2pdf -dPDFSETTINGS=/prepress or something.
(I don't want to assume too much of Adobe Reader since reading of later
versions not coming bundled with base fonts.) Still, I couldn't help but
notice that dvips' notion of `needed characters' seemed to be coming up
a bit short.

Mark

No problem.

I would be surprised if PDF where not good enough. If they really
request PS, you can always resort to pdftops to go back to ps with all
fonts included.

Because of this it is meanwhile quite standard for PDF files to
include all fonts. One of the reasons why nowadays a PDF based
workflow causes less problems.

The problem is simply that dvips cannot interpret the included PS
image, since it does not contain a PS parser. I would therefore
suggest to either close this bug or retitleit to "dvips should parse
included PS images to determin used fonts", lowering it to 'whishlist'
and tagging it as 'wontfix'. What do you think?

cheerio
ralf

Ralf Stubner <ralf.stubner@web.de> writes:

Oh - the DVI format still includes uninterpreted PostScript (the
included EPS figures)? Gosh. Now I come to look at xdvi's manpage I see
that indeed it does seem to call things like Ghostscript when necessary.

That seems very reasonable. Given `wontfix' at the Debian side, would
you be able to pass the wishlist item upstream? (Or is that done
routinely anyway?) Given that the DVI format seems capable of including
PostScript, and LaTeX-with-EPS to DVI to PostScript is a common usage
case of dvips, it seems bizarre for it to be so eager to attempt an
optimization it can't currently actually do safely.

I would put the idea in your mind of adding to the Debian dvips
manpage's -j option documentation a warning that it may not recognize
that characters from included diagrams are needed. I'll leave that
decision up to your judgment though. (-:

Thank you very much for your help, anyway. It's nice to be understanding
this a bit better now. It took me quite some time to pin down the
problem; if nothing else, I'm glad that Google will probably archive
this discussion ready for the next confused person! And I'm okay at my
end now I've added -j0 at the relevant points in my document-processing
scripts.

Mark

retitle 508528 dvips should parse referenced PS images to determin
used fonts
severity 508528 wishlist
tags 508528 wontfix
thanks

DVI files can contain raw PS code (eg when using pstricks), but it can
be even worse. In the current case of an included image, the DVI file
only contains a reference to the PS file, and that reference is not
some sort of standard feature of DVI but done via a so called special
command. These special comamnds can contain basically anything and it
is left to the DVI processor what to do with them. Fortunately the
number of DVI processors isn't all that hugh nowerdays, and there is
quite some overlap in the supported specials. Still, a DVI file
produced for dvips will not come out correctly when processed with
dvipdfm. And quite a lot of PostScript trickery that shows up
correctly after running dvips is invisible in xdvi.

I see no point in passing it upstream for several reasons. One is that
there is almost no development going on with respect to dvips. The
other is that this is a quite tricky problem. Basically you would need
a full PS interpreter to find out which glyphs from which fonts are
used in any referenced image.

I will see if I come up a with some propper wording for this. Though
it does not belong to the -j option from my point of view. The problem
is that you request dvips to (partially) download the base PS fonts
but at the same time use a EPS file that requires one of these base PS
fonts without including it. I do not know where this sort of
information should be put ...

cheerio
ralf

Ralf Stubner <ralf.stubner@web.de> writes:

That's sufficient reason in and of itself.

It's a pity it's not easier to simply ask ghostscript which fonts are
used, on systems where it's installed. I certainly agree that a full PS
interpreter would be out of place in dvips itself!

I had thought -j because it says `only needed characters' without
clarifying that it doesn't mean `for proper display of the document'
which, after all, is what one might reasonably assume that it does mean.
Though, it does make it trickier that I suspect that, like me, it's very
common that people use DVI tools without realizing that they often rely
on such documents containing important content that isn't `officially'
part of the DVI format.

Thank you very much, anyway. I have appreciated your responsiveness.

Mark