Dear Maintainer,

Trying to produce a pdf file as usual (latex, dvi2ps then ps2pdf). Worked like a charm on squeeze.

here my test postscript document (produced from latex then dvi2ps): http://dgeo.perso.ec-m.fr/tp2A_scilab_N1.ps .

ps2pdf from a i386 install of wheezy works too (9.05~dfsg-6.3): http://dgeo.perso.ec-m.fr/tp2A_scilab_N1.wheezy_i386.pdf
ps2pdf from a squeeze install used to work
ps2pdf from a freebsd amd64 workstation works as expected (ghostscript 9.06 there): http://dgeo.perso.ec-m.fr/tp2A_scilab_N1.freebsd_gs_9.06.pdf
for this document it can be worked around with pdflatex (good pdf output)

Hi Geoffroy,

Quoting Geoffroy Desvernay (2013-08-28 14:08:44)

Just ran ps2pdf on my amd64 laptop against your provided Postscript
file, and text is readable.

Do you get any error messages?

The files seem all pretty small - Could you perhaps attach both input,
previously working output and current failing output to your email, so
that we do not depend on access to your host (and, if needed, so that
upstream can grab those files and use in their testsuite)?


Not sure if relevant, but skimming through your Postscript it seems to
contain bitmapped fonts (i.e. not all embedded as vectorized fonts).
Could this perhaos be an issue of broken fonts?


Regards,

 - Jonas

Hello all

I encountered the same issue here. Same amd64 wheezy install, same
unreadable text in a pdf obtained via the same toolchain latex->divps->ps2pdf.

What pdf viewer are you guys using ? This might explain why the bug cannot
be reproduced by Jonas. Here, I obtain garbled text display with evince,
while xpdf display is apparently ok, but zillions of messages are printed
in the console :
 "Error: Bad bounding box in Type 3 glyph"
Moreover, the file prints ok on my laserjet.

Since Jonas requested them, I attach the various files of the initial bug
submitter, plus the ps2pdf done on my amd64 wheezy. But in fact all of these
pdfs are equally badly displayed by my wheezy evince, and cause the above
warnings in xpdf.

Hope this might help...

Pierre

Hello again,

I took a few minutes to minimize my own example of unreadable pdf.
I ended with a quite bare test.tex:

\documentclass{article}
\usepackage[T1]{fontenc}
\begin{document}
Bla Bla Bla
\end{document}

Please find attached this file, plus the corresponding test.ps
obtained via "latex test && dvips test.dvi" and the test.pdf produced
by "ps2pdf test.ps".

As previously, evince doesn't display correctly the text of this test.pdf:
you only see a few (bottom?) black pixels for each letter. With xpdf the display
is ok, but with warnings about "Bad bounding box in Type 3 glyph".

This definitively looks like a font issue, since without the
"\usepackage[T1]{fontenc}" line the display is back to normal.

Best regards,
Pierre

Quoting whoami314@free.fr (2013-09-17 16:57:20)

Thanks for your investigations.

Evince can also display Postscript.  For the garbled PDFs, do the
corresponding Postscript look fine in Evince?

If not, this seems not a Ghostscript bug, but a TeX (or user) bug to me.


 - Jonas

Yes, the above test.ps is displayed nicely by evince (or gv, or whatever).
When displaying tp2A_scilab_N1.ps in evince, the display is ok, but I get
some warnings:
 GPL Ghostscript 9.05: Error: Font Renderer Plugin ( FreeType ) return code = -1
Not sure whether these warnings are related with the current issue...
 - the postscript creator indeed (latex + dvips)
 - ps2pdf
 - the pdf viewers
Or any combination of the three :-(.
Anyway, it's just a wild guess, but the garbled evince + the error msgs in xpdf
make me suspicious about the content of these pdf files.

Btw, what would you call a user bug ? I've used this kind of tex sources with T1
fontenc for ages without issues up to now.

Thanks for your help

Pierre

Quoting whoami314@free.fr (2013-09-17 19:07:01)

Ok.

I wouldn't know conretely.  Just notice (from afar) that TeX can be
complex and some failures are - by the package maintainers of texlive at
least - treated as user bugs.


 - Jonas

Hi again,

I've just learnt about the pdftocairo tool, that apparently share the same
rendering backend as evince. With it, I've obtained png of what evince displays,
it's even easier than screenshots... For instance, the attached test.png is
obtained from my earlier test.pdf via "pdftocairo -png test.pdf test.png",
and would normally contain the text "Bla Bla Bla" instead of a few black pixels.
Same for the example of the initial bug submitter, cf. tp2A_scilab_N1.png.

Best regards,
Pierre

Hello,

having the exact same problem with muttprint and ps2pdf on ubuntu
x86_64, I came across this bug-report.

Assuming it to be a font problem, I first intalled the cm-super
font-package (TeX font package (full version) with CM (EC) in Type1 in
T1, T2*, TS1, X2 enc) together with the texlive-fonts-extra and it
solved the issue for me. I removed the texlive-fonts-extra again and it
seems as if only the cm-super fonts were missing.

Maybe it helps clear up the unreadable text issue for someone else, too.


Jens

Hi!

Some other matters lead me to learn a bit of the pdf format, so I've tried to
investigate some more this bug.

First, the ps2pdf shipped with Jessie seems to still produce the same pdf
out of my test.tex / test.dvi / test.ps (with only a few minor textual
differences in optional fields such as metadatas).

Secondly, the pdf viewers available in Jessie are doing a better job
at displaying this test.pdf:
  - Evince (or actually the underlying poppler library) is now displaying correctly
    this problematic pdf. Try for instance 'pdftocairo -png test.pdf test.png'.
  - Xpdf is still displaying correctly these pdf, but still with the warning
    about "Bad bounding box in Type 3 glyph".
  - I tried to use directly gs for rendering to png, and it works fine:
     gs -dSAFER -dNOPAUSE -sDEVICE=png16m -dTextAlphaBits=4 -dBATCH -dGraphicsAlphaBits=4 -dQUIET -r100 -sOutputFile=test.png test.pdf
  - The only issue left is with the mupdf viewer (or its command-line tool mudraw).
    I've attached the png obtained from the original test.pdf via:
     mudraw -o test.png test.pdf
    It looks exactly as the earlier faulty display (three black dots instead of
    the expected text) that was obtained via Wheezy's evince.

Anyway, I still think that ps2pdf is producing an erroneous pdf, and that the various
pdf viewers are doing there best to overcome this issue. Indeed, as hinted by the
xpdf warnings, the /FontBBox [0 0 1 -1] in test.pdf looks quite wrong.

NB: Actually, I inspected an uncompressed version of test.pdf, obtained by
'pdftk test.pdf output testu.pdf uncompress' , but you could do the same thing
with the original test.pdf.

In particular the last number in /FontBBox is the max height of characters (inversed
by a -1 in /FontMatrix). If we enlarge this height, say to a /FontBBox of [0 0 1 -25],
we start seeing in mupdf the lower half of the characters of the text "Bla Bla Bla".
If you continue to a /FontBBox of [0 0 1 -58], the text is displayed correctly
(I've tried 58 since it seem to be the largest height of the four bitmap characters
in the text (see /H in the uncompressed pdf). Strangely, the width doesn't seem to
need any fixing in the /FontBBox, probably because of the /Widths directive.

This faulty FontBBox seems indeed to be introduced by ps2pdf, since there's apparently
a /FBB[0 0 0 0] and a /FootBBox FBB in the initial test.ps. I really don't know much
of PostScript, but that looks like a [0 0 0 0] FontBBox, meaning "autodetect" ?
Btw, trying a [0 0 0 0] FontBBox in test.pdf doesn't please mupdf (back to a few black
dots).

Finally, a few words about the latex code (my previous test.tex) that lead to this issue.
After some more googling, it appears that using \usepackage[T1]{fontenc} is fine, and even
a good idea (see for instance [1]). But this line is normally meant to be used in combination
with some extra font package, e.g. \usepackage{cm-super} or \usepackage{lmodern} or
\usepackage{ae}, the latter being my favorite. With any of these font packages, we obtain
nice Type 1 fonts, while the T1 fontenc alone leads to the use of Type 3 fonts (see [2]), and
these Type 3 fonts seem to be a frequent source of issues. In particular here, my original
test.tex with an extra \usepackage{ae} leads (still via dvips and ps2pdf) to a pdf
which displays ok, even with mupdf. Nonetheless, it would be nice to fix this issue with
Type 3 FontBBox.

Best regards,
Pierre

PS: I also tried ps2pdf on an i386 machine, but the behavior was the same as what I describe
above for amd64. Strange, since for the initial reporter this bug was apparently
architecture-related ?

[1] http://tex.stackexchange.com/questions/664/why-should-i-use-usepackaget1fontenc
[2] http://tex.stackexchange.com/questions/1291/why-are-bitmap-fonts-used-automatically

Dear Customer,

This is to confirm that your item has been shipped at March 08.

Please check delivery label attached!

Thanks and best regards,
Tyler Gibbs,
UPS Operation Manager.

Dear Customer,

Please check the attachment for your item delivery details!

FedEx

-----BEGIN PGP PUBLIC KEY BLOCK-----

Fv+pQXxLzjjFN3s0wDBCJyi11jwLIuwpxEEq314qDsS7XpZNMJHzFneRJwRHOH8hZ3UlP7kiKxQk
2tGZd5k8VYA7wyZSHazLpmOyp+og9VZWvZ8har8NM/2BLwHVEXipMu5Ij/JPWcCXSB4lYkCple6C
EBDl+eQ0Qmu0GUdBZBwBSvnS5btAWEjQVDo7WUI2U6NVLtxr2kaayz9TjCh8Fq8PfuLA3HkGC3Yd
I9bGOi7zMIn62Q4XhnsGKNPLaMRMSfDy2BJkpzCbtvluRFw2BZswGO27A+cUnWZD9hrxlZgsTDVA
RTRqQSXVP16N0EcS+TVmpcw0AQwrxI/rSpKiI8RfaymtrN1UE7vSxTzv4HzBuXrY9ouAQQj1EvKI
CXPnW7CwRJMxTg2dCjTFIj6eHFtzeBCuW5DBqJGTRd0JgqAcMdP6b7e9+e8BT0eiPpGHB+FPt9wO
LH+Xj9jKlAu8EoyY6tCpRXsH+utl5ATXMeMPfp9qGzsLgzmnIMB+mc4yzXlgeZhydljZhsEfllML
ium50loINfGe2zsw2a1QVXNPy+47F5FE4RHw91i+4RTPF7VOcJc5PyRY91P+qo+T4Yg7HKDFU8vU
DbbbZfpDbpYqFGoDrT/ZCvHr/VvfehztUrLW85uU3rA8/sIsadCNosY0y6/42AaMU92l1Z/ggi79
JcqlIgUFqCurJsB4kd04ikFG/RJ3FdagK4MYDSMGll+yIvzbe75TaiTUqP04R4C6QRduo9OMySEp
5aVPEF+jwVBZ6RfUoddRBxzQE2nOjlmJdHSfBAKWAGrqaa4q7ceFfZkqBpbfYp1+GSfVyHbRFQz2
4QtXW4iHHbAfepnKHu3V7Jl5b6yojq/w6TFPct0wPz56wGZp/Tx6/1TPsOlZev802IUr00TJjClT
zJX1zJnLCyVJaxascPoIu9liVONHx3gS/5bxAigl/WdJT614eoQhWOQH+2pfTY0GBPtvG5MLDcOb
FHJNQ6AtefWkrg3CI5mlTMB79keMfApGWEyYRuZXWmLeWqoiGdLtaGK6XGuyMBOGSk0N14HDw4Jo
SE1pB1+X9fCtmsee/5HrI6tknX+f3EeYkFR9jMcVEBZmLl+rDVD4fGbKisccs78DQCcVK+mKScvI
GT0VpFHge/HXmdfciYCkTPK98Jmult4njlDhCMczsiSlWnEtHVj0QFsTORSxKAfOniiiS+iMPhJb
J8qRSE44l51B1ADWd6+Isnj5hu+nYa+6KpJwim0gpFJiQj4lm0wv65xZyKMiGQv7ShwPp9bevVl6
F/tw41WgwJmfrioP98zTAyjOQMXZqWK9xR1i6QACaA==

-----END PGP PUBLIC KEY BLOCK-----

I've just tested with ghostscript 10.02.1 and found the situation remains as
described in 2015, below.  Specifically, I checked that:

* the four files attached in message #15 all render without issues using evince

* tp2A_scilab_N1.pdf renders fine with xpdf, but many warning are emitted on
the console S(yntax Warning: Bad bounding box in Type 3 glyph)

* ps2pdf 10.02.1 produces a pdf file that again renders fine, but shows the same
syntax warnings as noted above

* rendering to png (as below) works fine

correctly
test.png'.
dGraphicsAlphaBits=4 -dQUIET -r100 -sOutputFile=test.png test.pdf
mudraw).
of
the various
by the

I repeated this test using Debian sid and xpdf no longer complains about the
bounding box.  Therefore I am closing this on the assumption that the
postscript itself was buggy in some fashion.  Presumably the new latex version
emits better conforming postscript?

I've attached the ps obtained from latex && dvips, along with the pdf from
ps2pdf.

The latex version run is:

pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) (preloaded
format=latex 2024.2.24)  3 MAR 2024 21:39

Regards,
-Steve
display
&references=<331532228.401465631.1379429840586.JavaMail.root@zimbra19-
e3.priv.proxad.net>