Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Does anyone know of a "lint" for Postscript?

41 views
Skip to first unread message

Thomas Gagne

unread,
Apr 29, 2010, 3:24:12 PM4/29/10
to
I was recently told by a guy in the commercial print business that some
printer manufacturers won't claim responsibility for a bug in printing
Postscript if the Postscript isn't "certified" somehow.

It sounded odd to me, but I understand the point. Postscript is a
sophisticated-enough language that not every Postscript file could be
"correct" even if a printer is able to "correct"ly render it.

Which made me wonder, is there such a thing as testing a Postscript file
for correctness? Similar to how C may be run thru "lint" or even
compiled for syntactic correctness.

Helge Blischke

unread,
Apr 29, 2010, 4:30:15 PM4/29/10
to
Thomas Gagne wrote:

Just run the PostScript file through a PostScript interpreter. I think
Ghostscrip is a good choice. For example, run the command

gs -sDEVICE=nullpage -dNOPAUSE -c save pop -f example.ps -c quit

If it does not spit out error messages, you can be almost certainly sure
that the file is OK.

Another choice is - if you have Acrobat Distiller - to run the file through
distiller.

Helge

P.S.: as for "almost certainly": there may be cases that the printer's PS
interpreter deviates from the Adobe reference implementation(s) in some
respect, and it may be that Ghostscript complains about device specific
settings for the printer.

Thomas Gagne

unread,
May 2, 2010, 8:23:55 PM5/2/10
to
One problem I think GS has is it tries to interpret the entire file at
once. I seem to remember GS freaking out with a file I sent it several
hundred MB long. I don't have the file handy so I'll have to test it again.

Helmut Jarausch

unread,
May 3, 2010, 4:47:32 AM5/3/10
to
On 04/29/10 22:30, Helge Blischke wrote:
> Thomas Gagne wrote:
>
>> I was recently told by a guy in the commercial print business that some
>> printer manufacturers won't claim responsibility for a bug in printing
>> Postscript if the Postscript isn't "certified" somehow.
>>
>> It sounded odd to me, but I understand the point. Postscript is a
>> sophisticated-enough language that not every Postscript file could be
>> "correct" even if a printer is able to "correct"ly render it.
>>
>> Which made me wonder, is there such a thing as testing a Postscript file
>> for correctness? Similar to how C may be run thru "lint" or even
>> compiled for syntactic correctness.
>
> Just run the PostScript file through a PostScript interpreter. I think
> Ghostscrip is a good choice. For example, run the command
>
> gs -sDEVICE=nullpage -dNOPAUSE -c save pop -f example.ps -c quit

>
> If it does not spit out error messages, you can be almost certainly sure
> that the file is OK.

Unfortunately, several postscript files generated by acroread-9.3.2 (on Linux)
pass this check but make some printer hang though these are specified for
postscript level 3.
Furthermore even gv or evince have problems showing only the first sheet or
only the upper part of a sheet. (I've asked acrocread to
place 4 pages onto a sheet of paper in a 2x2 manner.)

Any ideas what is in error?

Thanks for some hints,
Helmut.


--
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

Helge Blischke

unread,
May 3, 2010, 6:54:58 AM5/3/10
to
Helmut Jarausch wrote:

I came across this issue with various versions of Adobe reader on
Linux/Solaris.
Could you please post (an URL to) a sample PDF and reader generated PS?

Helge

Helmut Jarausch

unread,
May 4, 2010, 4:36:20 AM5/4/10
to

Helge Blischke

unread,
May 4, 2010, 6:00:26 AM5/4/10
to
Helmut Jarausch wrote:

Sorry, I've no rights to read the PostScript file ...

Helge

Helmut Jarausch

unread,
May 4, 2010, 6:45:25 AM5/4/10
to
Sorry, hopefully the rights are OK now (it's sshfs-mounted and therefore it's
difficult
to see the actual rights)

ken

unread,
May 4, 2010, 6:50:29 AM5/4/10
to
In article <84a4k2...@mid.dfncis.de>, jara...@igpm.rwth-aachen.de
says...

Like Helge I can't access the PostScript file, so my comments are
somewhat general and speculative.

In the PDF file there is a small logo at the bottom left of each page,
this logo is transparent. In fact the logo appears to be needlessly
complex. It is drawn as an image XObject, which consists of a form,
which contsists of an image...

The final image is a soft mask and it 'looks' like the form which
contains the image covers the whole page.

Now PostScript does not support transparency, so when you convert a PDF
file which contains transparency into PostScript, some or all of the
content is rasterised into an image at a target resolution. This results
in image data being embedded in the PostScript in place of the original
content.

Because the form containing the image covers the whole page (even though
only a small part at the bottom left actually contains anything) it
seems likely that the whole page is being rendered to a bitmap. This
results in large PostScript files.

In addition, its possible that the PDF form is being converted into a
PostScript form. PostScript forms are intended for data which is common
across many pages, its a form of cache which speeds rendering when the a
multi-page file consists mostly of the same data on each page.

This means the data in the form must be cached, if the data is a large
bitmap, its entirely possible, especially on a printer with limited
memory, that it will be unable to cache the form, and so emits an error.
Of course Ghostscript, running on a desktop computer with lots of
physical memory, a disk and virtual memory available by using the disk
has no problems running the file.

In this case there is nothing actually wrong with the PostScript, its
perfectly valid, it just can't be run on a printer with a small amount
of memory. So a lint like tool wouldn't tell you anything. The only way
to find out how much memory a program needs is to execute it.....

Remember PostScript is a programming language, this is equivalent to
trying to run some large applicaiton on your computer with only limited
memory available. The fact that it runs on your colleagues 64-bit
computer with 64GB of memory, but not on your computer with 128KB does
not mean the program is at fault.


Ken

ken

unread,
May 4, 2010, 6:59:24 AM5/4/10
to
In article <qNidnada7IQBikPW...@wow.com>,
TandGa...@gmail.com says...

> One problem I think GS has is it tries to interpret the entire file at
> once.

No, this isn't possible. A PostScript program is interpreted, you have
to start at the beginning and proceed to the end, because procedures and
objects can be redefined during the course of the program you can't
interpret the file any other way.

> I seem to remember GS freaking out with a file I sent it several
> hundred MB long.

Ghostscript happily reads, interprets, and renders files of any length,
and our standard testing includes large input files. Memory restrictions
may cause memory exhaustion (VMError) in the case of files which define
many PostScript objects, when a non-banding device is asked to render at
high resolution, or when a non-banding device is asked to handle
transparency at moderate resolutions.

Other more obscure conditions can also cause memory exhaustion.

Running out of disk space (or swap space on Unix systems) can also cause
VMError and are usually caused by running files at high resolution
(and/or large media sizes).


And of course we are continually fixing reported bugs, just like all the
other PostScript interpreter vendors.


Ken

ken

unread,
May 4, 2010, 6:59:24 AM5/4/10
to
In article <84ac65...@mid.dfncis.de>, jara...@igpm.rwth-aachen.de
says...

> Sorry, hopefully the rights are OK now (it's sshfs-mounted and therefore it's
> difficult
> to see the actual rights)

I cna read the file, and I can't see anything unusual about it. It may
well not work on a level 2 PostScript printer (it states itself to be a
level 3 file), but should be fine on anything newer.

Ghostscript peaks at 34MB running the file at 96 dpi, obviously more
would be required for rendering a higher resolution image but it shows
the file is not using exceptional amounts of memory.


Ken

Helmut Jarausch

unread,
May 4, 2010, 7:03:31 AM5/4/10
to
On 05/04/10 12:50, ken wrote:

> In the PDF file there is a small logo at the bottom left of each page,
> this logo is transparent. In fact the logo appears to be needlessly
> complex. It is drawn as an image XObject, which consists of a form,
> which contsists of an image...
>

Many thanks, Ken.
Do you know about a Linux tool to remove such a logo?

Helmut.

PGAGA

unread,
May 4, 2010, 8:06:47 AM5/4/10
to
Tuesday, May 04, 2010

Not sure what is happening here, but on my Ubuntu 10.4 setup the PS
file is viewable in Document Viewer, GV and GSview. The Ghostscript
on the system is 8.71 using my customized Fontmap.

Phil

ken

unread,
May 4, 2010, 8:06:36 AM5/4/10
to
In article <84ad83...@mid.dfncis.de>, jara...@igpm.rwth-aachen.de
says...

Umm, no, not really. I can do it here with Acrobat Professional, on
Windows. A good PDF editing tool should be able to do it.

I'm not certain that's your problem though, as the PostScript produced
from it seems quite simlpe.


Ken

Helge Blischke

unread,
May 4, 2010, 10:04:31 AM5/4/10
to
Helmut Jarausch wrote:

Helmut,

now that you did change the permissions, I could download the PS file and do
some tests with it, and all were successful so far:
- Ghostscript (8.64 on Mqac os X) shows your 4-up file perfectly
- my PS printer (an OKI C3600, PS Level 3) prints it perfectly
- even gv (version 3.6.7) displayed it nearly perfectly (shifted upward
because of the bounding box comments).

So, as a resume, I can state the following:

(1) The %%BoundingBox comment(s) specify the bounding box of the document
according to Adobe's DSC specification, i.e. describing the smallest
rectangle containing any non-white marks througout the file.
This disturbes utilities like gv, GSView etc., as these interprete the
bounding box as the media size (which is common but contradicts the Adobe
spec).

(2) The prolog contains a lot of direct references to systemdict (such as
systemdict/makepattern) which *may* interfere with operator redefinitions
inserted by the spooler system used.

(3) Most procedures in the prolog are only registered (using the def
operator) but not bound (i. e. not terminated by bind def). That might cause
endless redefinition loops in certain rare cases to my experience.

Perhaps you could tell the make and model of the printer you used for
further investigation?

Helge

P.S.: I don't think the complicated logo ken was complaining about is the
culprit.

Helmut Jarausch

unread,
May 6, 2010, 9:47:12 AM5/6/10
to

Yes, you're right. Using gs by itself is OK, but gv shows the upper
2 slides (of 4 per page) only (or the upper 2 pages are shifted out)
So, it seems like a bug in 'gv'.

On the other hand, evince displays the first 4 pages ( = first sheet) just fine
but if one asks it to show the next 4 pages, it displays just 'Loading ...'
forever (without consuming CPU time)
I think this is similar to what happens with my printer.

Thanks,
Helmut.

Helmut Jarausch

unread,
May 6, 2010, 9:50:05 AM5/6/10
to
On 05/04/10 16:04, Helge Blischke wrote:

> Perhaps you could tell the make and model of the printer you used for
> further investigation?
>
> Helge
>
> P.S.: I don't think the complicated logo ken was complaining about is the
> culprit.

First, as reported in an answer to PGAGA's mail, evince hangs, as well.
My printer is an NRG DSm415 PS3 copier using Postscript Level 3 Version
3011.103 (0)

Thanks,
Helmut.

PGAGA

unread,
May 6, 2010, 10:31:46 AM5/6/10
to
Thursday, May 06, 2010

> > Not sure what is happening here, but on my Ubuntu 10.4 setup the PS
> > file is viewable in Document Viewer, GV and GSview.  The Ghostscript
> > on the system is 8.71 using my customized Fontmap.
>
> Yes, you're right.  Using gs by itself is OK, but gv shows the upper
> 2 slides (of 4 per page) only (or the upper 2 pages are shifted out)
> So, it seems like a bug in 'gv'.

I have found differences/bugs in different versions of GS in Windows.
In the case of Win32 and Win64, I have had to temporarily set GSview
to 8.70 with the occasional merged file.

Checking GV again on my system, the problem appears to be the
inability of GV to handle custom page sizes. GSview can do that and
displays the file properly.

Phil

Helge Blischke

unread,
May 7, 2010, 1:24:32 PM5/7/10
to
Helmut Jarausch wrote:

What spooler do you use for your printer (CUPS, LPRng, some other)?

Helge

Helge Blischke

unread,
May 7, 2010, 4:25:04 PM5/7/10
to
Helmut Jarausch wrote:

I just set up a virtual system using Gnome as desktop manager (freeBSD 8.0)
and tested your file with evince, and that application indeed hung after
displaying the first page.
In a second test, starting evince from the command line, it comlained about
the PS file when rendering the thumbnails as follows:

** (evince:1531): WARNING **: Error rendering thumbnail
undefined -21
undefined -21

which is the first component in an array within a subsetted embedded font.

The Ghostscript version is 8.64, but the variant using the Ghostscript
shared library. It is known that this setup has a bug when reading the
PostScript job from standard input, if stdin is not attached to a terminal,
and the error message above looks like other complaints due to this bug I've
seen.

It is also known that the bug has been fixed with Ghostscript 8.71. You
should therefor update your ghostscript, compiling from the sources, if
necessary.

Helge

P.S.: I'll try that within the next couple of days, I think.

Helge Blischke

unread,
May 8, 2010, 4:24:19 AM5/8/10
to
Helmut Jarausch wrote:

One more suspicion about your problem with respect to your printer:
IF your spooler is CUPS, AND you used the pxlmono driver for your printer,
which uses Ghostscript to convert the PostScript pages to bitmapped images,
then you'll encounter the very same issue as with evince, as Ghostscript,
called from the foomatic-rip filter, reads from standard input as well.

So, the best advice I can gibe you is to update Ghostscript to the current
version, 8.71.

Helge

Helmut Jarausch

unread,
May 10, 2010, 4:33:57 AM5/10/10
to

CUPS-1.3.11

Thanks,
Helmut.

Helmut Jarausch

unread,
May 10, 2010, 4:38:53 AM5/10/10
to
On 05/08/10 10:24, Helge Blischke wrote:
> So, the best advice I can gibe you is to update Ghostscript to the current
> version, 8.71.
>
> Helge
>

Unfortunately, I'm using Ghostscript 8.71 (running a bleeding edge Gentoo system).
Thanks, Helge, anyway.

Helmut.

Helge Blischke

unread,
May 10, 2010, 11:27:57 AM5/10/10
to
Helmut Jarausch wrote:

From your previous posts I presume that your printer speaks PostScript
natively, so you should use the NRG supplied PostScript PPD, available at

http://www.openprinting.org/ppd-o-matic.php?driver=Postscript-
NRG&printer=NRG-DSm415&show=0

Or, if that is not an option, you could compile another Ghostscript instance
not using the dynamic Ghostscript library.

Helge

Helmut Jarausch

unread,
May 14, 2010, 4:55:31 AM5/14/10
to
On 05/10/10 17:27, Helge Blischke wrote:
> Helmut Jarausch wrote:
>
>> On 05/08/10 10:24, Helge Blischke wrote:
>>> So, the best advice I can gibe you is to update Ghostscript to the
>>> current version, 8.71.
>>>
>>> Helge
>>>
>>
>> Unfortunately, I'm using Ghostscript 8.71 (running a bleeding edge Gentoo
>> system). Thanks, Helge, anyway.
>>
>> Helmut.
>
> From your previous posts I presume that your printer speaks PostScript
> natively, so you should use the NRG supplied PostScript PPD, available at

Yes, it has. The postscript file is sent (directly?) to the printer by CUPS.
I just wondered about your advice to update Ghostscript.

Unfortunately, I don't know about any method to find out how much
memory this printer has installed (The testpage doesn't show it.)

Thanks,
Helmut.

Helge Blischke

unread,
May 14, 2010, 2:45:54 PM5/14/10
to
Helmut Jarausch wrote:

What is happening if you specify the 4-up options as cups options instead of
Adobe reader options?

Helge

0 new messages