Bug#508528: texlive-base-bin: dvips without -j0 causes missing characters in output
Mark T.B. Carroll
Version: 2007.dfsg.2-4
Severity: normal
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
-- Package-specific info:
If you report an error when running one of the TeX-related binaries
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report. Don't forget to also include minimal examples of
other files that are needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!
If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at
http://www.latex-einfuehrung.de/mini-en.html (english)
or
http://www.latex-einfuehrung.de/mini.html (german)
##################################
minimal input file
problem.tex -
\documentclass[english]{article}
\usepackage{babel}
\usepackage{geometry}
\geometry{verbose,letterpaper,tmargin=1in,bmargin=1in,lmargin=1in,rmargin=1in}
\usepackage{graphicx}
\usepackage{mathptmx}
\begin{document}
Hello, here is a graphic.
\includegraphics{graphics.epsi}
There it is.
\end{document}
##################################
other files
100 100 moveto
/Times-Roman 10 selectfont
(I am a graphic, written in straight PostScript.) show
showpage
######################################
List of ls-R files
-rw-r--r-- 1 root root 896 2008-12-11 20:05 /var/lib/texmf/ls-R
-rw-rw-r-- 1 root staff 79 2008-12-11 20:05 /usr/local/share/texmf/ls-R
lrwxrwxrwx 1 root root 29 2008-12-11 10:36 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 27 2008-12-11 20:05 /usr/share/texmf-texlive/ls-R -> /var/lib/texmf/ls-R-TEXLIVE
lrwxrwxrwx 1 root root 27 2008-12-11 20:05 /usr/share/texmf-texlive/ls-R -> /var/lib/texmf/ls-R-TEXLIVE
######################################
Config files
lrwxrwxrwx 1 root root 20 2008-12-11 10:36 /usr/share/texmf/web2c/texmf.cnf -> /etc/texmf/texmf.cnf
-rw-r--r-- 1 root root 4985 2008-12-11 20:05 /var/lib/texmf/web2c/fmtutil.cnf
-rw-r--r-- 1 root root 7512 2008-12-11 20:05 /var/lib/texmf/web2c/updmap.cfg
-rw-r--r-- 1 root root 4569 2008-12-11 20:05 /var/lib/texmf/tex/generic/config/language.dat
######################################
Files in /etc/texmf/web2c/
total 4
-rw-r--r-- 1 root root 283 2007-01-15 02:53 mktex.cnf
######################################
md5sums of texmf.d
42c20d7e8bd343542772b5a145bf8ad8 /etc/texmf/texmf.d/05TeXMF.cnf
5f7f6652cc8b8071c9e4ea6ba9e9f0a1 /etc/texmf/texmf.d/15Plain.cnf
f68e5add6afd6585b982f2f78e2e6a92 /etc/texmf/texmf.d/45TeXinputs.cnf
ea33127256c6a9f37145ae5b16fdb80c /etc/texmf/texmf.d/55Fonts.cnf
afccf1d3f87057411166a77c58e00bd1 /etc/texmf/texmf.d/65BibTeX.cnf
9da7c1c7b1eaf06f941af91f48a23068 /etc/texmf/texmf.d/75DviPS.cnf
7ae52efac46feb97010986e57877d12e /etc/texmf/texmf.d/80DVIPDFMx.cnf
37329819f1109e8a457e64b8b58fecdb /etc/texmf/texmf.d/85Misc.cnf
a8952d594677235951d447665ec46e9c /etc/texmf/texmf.d/90TeXDoc.cnf
30f4f13357c2761ed01a6a15f28725a5 /etc/texmf/texmf.d/95NonPath.cnf
1df66bc319cec731e202eaf39f5d85e1 /etc/texmf/texmf.d/96JadeTeX.cnf
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable'), (50, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.26-rc8
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages texlive-base-bin depends on:
ii ed 0.2-20 The classic unix line editor
ii libc6 2.7-4 GNU C Library: Shared libraries
ii libgcc1 1:4.2.2-4 GCC support library
ii libkpathsea4 2007.dfsg.2-3 TeX Live: path search library for
ii libncurses5 5.6+20080203-1 Shared libraries for terminal hand
ii libpng12-0 1.2.15~beta5-1 PNG library - runtime
ii libpoppler3 0.8.2-2 PDF rendering library
ii libstdc++6 4.2.2-4 The GNU Standard C++ Library v3
ii libx11-6 2:1.0.3-7 X11 client-side library
ii libxaw7 1:1.0.2-4 X11 Athena Widget library
ii libxmu6 1:1.0.2-2 X11 miscellaneous utility library
ii libxpm4 1:3.5.5-2 X11 pixmap library
ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library
ii mime-support 3.39-1 MIME files 'mime.types' & 'mailcap
ii perl 5.10.0-17 Larry Wall's Practical Extraction
ii texlive-common 2007.dfsg.1-4 TeX Live: Base component
ii zlib1g 1:1.2.3.3.dfsg-7 compression library - runtime
Versions of packages texlive-base-bin recommends:
pn texlive-base-bin-doc <none> (no description available)
Versions of packages tex-common depends on:
ii debconf 1.5.11etch2 Debian configuration management sy
ii ucf 2.0020 Update Configuration File: preserv
Versions of packages texlive-base-bin is related to:
pn tetex-base <none> (no description available)
pn tetex-bin <none> (no description available)
pn tetex-extra <none> (no description available)
ii tex-common 1.11.3 common infrastructure for building
-- debconf information:
tex-common/check_texmf_wrong:
tex-common/check_texmf_missing:
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Stubner
thnaks for your report.
On Thu, Dec 11, 2008 at 21:31 -0500, Mark T.B. Carroll wrote:
> Package: texlive-base-bin
> Version: 2007.dfsg.2-4
> Severity: normal
>
> 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
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
Mark T.B. Carroll
> I suspect that dvipsDownloadBase35 is set to true
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.
> 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?
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
Ralf Stubner
> 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.
No problem.
> 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 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.
> (I don't want to assume too much of Adobe Reader since reading of later
> versions not coming bundled with base fonts.)
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.
> Still, I couldn't help but
> notice that dvips' notion of `needed characters' seemed to be coming up
> a bit short.
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
Mark T.B. Carroll
> The problem is simply that dvips cannot interpret the included PS
> image, since it does not contain a PS parser.
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.
> 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?
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
Ralf Stubner
used fonts
severity 508528 wishlist
tags 508528 wontfix
thanks
On Mon, Dec 15, 2008 at 10:35 -0500, Mark T.B. Carroll wrote:
> Ralf Stubner <ralf.s...@web.de> writes:
>
> > The problem is simply that dvips cannot interpret the included PS
> > image, since it does not contain a PS parser.
>
> 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.
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 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?
>
> 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 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 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. (-:
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
Mark T.B. Carroll
> 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.
That's sufficient reason in and of itself.
> 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.
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 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 ...
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