[NTG-pdftex] another problem -- of pdftex or gs?

Reinhard Kotucha reinhard.kotucha at web.de
Sat Feb 10 21:58:12 CET 2007

>>>>> "Thanh" == Thanh Han The <hanthethanh at gmail.com> writes:

  > Hi, the following file caused gs to segfault:

  > http://www.sendspace.com/file/ol6tlx

  > The command I used is:
  > ,-------- 
  > | gs -dNOPAUSE -sDEVICE=nullpage -sOutputFile=/dev/null -dBATCH survey-vn.ps  
  > `--------

  > and gs -v gave:

  > ,--------
  > | GPL Ghostscript 8.01 (2004-01-30) 
  > | Copyright (C) 2004 artofcode LLC, Benicia, CA.  All rights reserved. 
  > `--------

  > The ps file was converted by pdftops from survey-vn.pdf, the
  > vietnamese translation of the free math font survey by Stephen
  > G. Hartke, compiled by pdftex. The pdf itself and the ps converted
  > by acroread didn't cause the problem with the above
  > command. Another thing to notice is that the problem doesn't occur
  > with other devices, for example gv showed the file quite normally,
  > and the device ppm also works fine.

  > Maybe some PS guru here (eg Reinhard) can figure out what is wrong
  > with the ps file?

I'm not sure that there is something wrong with the ps file and I'm
not able to reproduce this with gs-8.01.  However, there are problems
with other versions.  Some versions hang, so I had to limit CPU time
in order to ba able to check with all versions I have installed.

$ for v in `gs --versions`;do (ulimit -t 10;GS=$v gs -dNOPAUSE -sDEVICE=nullpage -sOutputFile=/dev/null -dBATCH survey-vn.ps 2>&1 ; echo "exit status=$?");done | sed -e /^Copyright/d -e /^This/d
GNU Ghostscript 6.52 (2001-10-20)
exit status=0
GNU Ghostscript 6.53 (2002-02-13)
exit status=0
AFPL Ghostscript 7.03 (2001-10-20)
exit status=0
AFPL Ghostscript 7.04 (2002-01-31)
exit status=0
GNU Ghostscript 7.05 (2002-04-22)
exit status=0
GNU Ghostscript 7.06 (2003-04-01)
exit status=0
GNU Ghostscript 7.07 (2003-05-17)
exit status=0
AFPL Ghostscript DEVELOPMENT RELEASE 7.20 (2002-04-03)
exit status=139
AFPL Ghostscript DEVELOPMENT RELEASE 7.22 (2002-08-06)
exit status=139
AFPL Ghostscript 8.00 (2002-11-21)
exit status=0
GPL Ghostscript 8.01 (2004-01-30)
exit status=0
AFPL Ghostscript BETA RELEASE 8.10 (2003-05-21)
exit status=0
AFPL Ghostscript 8.11 (2003-08-16)
exit status=0
AFPL Ghostscript 8.12 (2003-12-08)
exit status=137
AFPL Ghostscript 8.13 (2003-12-31)
exit status=137
AFPL Ghostscript 8.14 (2004-02-20)
exit status=137
GPL Ghostscript 8.15 (2004-09-22)
exit status=137
AFPL Ghostscript BETA RELEASE 8.30 (2004-05-29)
exit status=0
AFPL Ghostscript BETA RELEASE 8.31 (2004-08-28)
exit status=0
AFPL Ghostscript BETA RELEASE 8.32 (2004-10-26)
exit status=0
AFPL Ghostscript BETA RELEASE 8.33 (2004-11-20)
exit status=0
AFPL Ghostscript 8.50 (2004-12-10)
exit status=0
GPL Ghostscript 8.51 (2006-05-27)
exit status=0
AFPL Ghostscript 8.53 (2005-10-20)
exit status=0
GPL Ghostscript 8.54 (2006-05-17)

Exit status 139 means that a segmentation fault occurred and 137 means
that the process had been killed by the shell when the CPU-time limit
of 10 seconds had been exceeded.

Assume there is a bug in the ps file, how is it possible to display
the file or convert it to other formats properly?

Curiously you get different results depending on -dNOPAUSE and
-dDEBUG.  I tried with gs-7.22.

   gs -sDEVICE=nullpage -sOutputFile=/dev/null -dBATCH survey-vn.ps

leads to a segmentation fault.  Adding -dDEBUG and removing -dNOPAUSE
tells me that the problem occurrs on page 15.

$ gs -dDEBUG -sDEVICE=nullpage -sOutputFile=/dev/null -dBATCH survey-vn.ps
**** DSC comment: /Page
<< /DSC_struct -dsc_data_struct- /PageNum 15 >>
**** DSC comment: /PageOrientation
<< /PageOrientation 0 /DSC_struct -dsc_data_struct- >>
Segmentation fault

But if I put -dNOPAUSE back again everything works:

$ gs -dDEBUG -dNOPAUSE -sDEVICE=nullpage -sOutputFile=/dev/null -dBATCH survey-vn.ps
**** DSC comment: /Page
<< /DSC_struct -dsc_data_struct- /PageNum 24 >>
**** DSC comment: /PageOrientation
<< /PageOrientation 0 /DSC_struct -dsc_data_struct- >>

I suppose that gs is so buggy that it doesn't make sense to use it as
a validator.

Maybe you get another result too if you add -dDEBUG too.

gs-8.01 is probably broken anyway.  I remember that 8.00 had not even been
able to process files created by dvips properly.  In composed words
containing a hyphen (quite common in German) gs added negative kern in
front of the hyphen.  Don't remember when it had been fixed but it is
quite likely that 8.01 still contains this bug.

Recently someone asked me for help.  He found me when he searched
Google for "/invalidfont".  He was using gs-8.54, the latest GPL
release, on Windows.  He got an error message, at least, but gs-8.54
on Linux did not complain about his file but silently aborted with a
segmentation fault.  It worked properly for me with 8.51 and obviously
he switched to this version too and is happy with it.

Karl also said that he encountered many segmentation faults in 8.54.

In my opinion gs is too unstable to rely on it.

Probably the reason for this particular problem is that gs is quite
large and new features are added while nobody has enough time to look
into old stuff, and I suppose that the nullpage device is such old

So, how can we validate a pdf file?  Well, I think that xpdf is a
first step.  If pdftops doesn't complain we know that the pdf file is
not completely broken.

There are two ways to extract and examine Type1 fonts:

1. My Perl script xtractfonts extracts Type1 fonts from pdf files
   (using pdftops at the moment but should work with acroread also)
   and disassembles them using t1diasm.  Adding Eddie's t1lint can be
   done easily.
2. pdftosrc can be used to extract objects from a pdf file and Hartmut
   successfully retrieved some fonts and disassembled them using the
I suppose that pdftosrc can be used to extract other things too and
external programs can be used for validation.

Thanh, I find http://www.sendspace.com extremely annoying.

Unless you forgot your passwd you can copy files to
thanh at ms25.ath.cx/public_html and ask people to download them from
http://ms25.ath.cx/~thanh .


Reinhard Kotucha			              Phone: +49-511-4592165
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.

More information about the ntg-pdftex mailing list