Bug 78450

Created attachment 86265 [details]
Imvalid level1 ps generated by printing from Linux Mozilla.

Created attachment 86266 [details]
Valid level1 postscript generated by printing from Windows Mozilla.

Till Kamppeter at linuxprinting.org provided a generic postscript driver that
has the needed level2->level1 pre-filtering option for the driver (see
discussion thread "generic ps driver that converts level2 to level1" in the
linuxprinting.general forum at http://www.linuxprinting.org). I have tested this
extensively. Unfortunately it fails to remedy the problem because ghostscript
7.05 is generating invalid level1 postscript. The 2 attachments were generated
by printing the same web page using Mozilla running under Linux and Windows. The
Linux generated ps does not print (even under Windows), but the Windows version
prints flawlessly. Both versions can be viewed via gv, but the Linux version has
very noticeably degraded quality. I'll report this to the ghostscript
maintainers, but please don't wait on them. Please take some initiative in
correcting this faulty component present in your distribution. Thank you.

'printer-config' is the wrong component to use.  Correcting.

Reassigning.

Created attachment 86364 [details]
Please try this file on the printer.

I confirm that there is a problem in pdfwrite driver in Ghostscript.
The driver alloactes insufficient space for the image cache. Please try the
attached file on the printer. The file increases page dictionary size 
to 197 entries.

Here's the results of trying to print lin801.ps:

1. Under Linux with old default Postscript driver (has no prefiltering option):
produces blank sheet of paper

2. Under Linux with T. Kamppeter's Generic Postscript driver (has prefiltering
option): nothing printed

3. Under Windows 2000: prints, but the result is of poor quality 

I'm not sure what can be concluded from this. There is definitely a postscript
problem, but is there also another problem with the printing system? Why doesn't
the stock RH8 Postscript driver print this when Windows is able to??

I can display lin801.ps with gv (ESP GhostScript 7.05.5 on Mandrake 9.0) and can
also print it on the HP LaserJet 4050 by simply sending it to the printer
without any filters. Probably this is the fix and we should patch GhostScript
appropriately. If it affects also PDF creation the fix is even much more
important, as nearly everyone creates PDFs, but only very few people have an old
PostScript Level 1 printer.

My first test with lin801.ps was without a filter. It failed. Also a comparison
of lin801.ps vs. l1ps_win.ps makes it obvious that there is a serious quality
problem with gs. Old printer or not, why is it that Windows 2000 can print
correctly but Linux can't?? I don't see how based on the evidence I presented
anyone can reach the conclusion that this "is the fix". From my perspective
nothing has been fixed.

lin801.ps is a PostScript file. You don't need any PS drivers to print it on a
PS printer -- just lpr it to the right queue. This file has a larger dictionary to
avoid dictfull error. This fix doesn't affect PDF at all. Please try lin802.ps.
Besides larger dictionary it uses procedure data source instead of string data
source and has an error handler.

Created attachment 86386 [details]
Please try this on the printer

Yes, I'm perfectly aware the lin801.ps is postscript. When you setup a print
queue using redhat-config-printer you are asked to select a driver. There's no
getting around that. And I obviously need one since I need the level2->level1
pre-filtering. Actually it's lpdomatic that does this, but it gets installed
along with the Generic Postscript driver. 

Here's the result of printing lin802.ps:

1. Prints under Linux with the default LPRng Postscript driver. Poor hardcopy
quality though (compare to l1ps_win.ps hardcopy).

2. Does *NOT* print under Linux with Generic Postscript driver neither with
pre-filtering enabled nor disabled.

I'll take being able to print for now if I can get it. How do I obtain the gs
patch and apply it (gs 7.05 was installed from rpm)? Unfortunately the initial
impediment of not being able to convert level2 to level1 remains.

Before I conclude this post perhaps you could entertain some naive questions.
What accounts for the stark difference is ps structure between l1ps_win vs.
lin801/802, and how does that relate to the hardcopy quality? Can gs do what
seems to be done in Windows, a compatibility mode perhaps?

My thanks to everyone, especially Till & Alex for their prompt attention to this
thorny problem.

lin801/802.ps files were derived from l1ps_linux.ps generated by Mozilla on Linux.
l1ps_win.ps was generated by Pscript.dll Version 5.0. These files look different
and the file generated on Windows looks better. You cannot blame Ghostscript for
this.

Attached is a patch aganst current CVS code that allocates larger dictionary and
uses a procedure instead of a string as a data source for the image operator.
That's all that can be done on Ghostscript side.

I'd consider working on other aspects of this problem as a consulting project.

Created attachment 86446 [details]
patch for GS 8.00

Thanks. I'm not sure why I can't blame ghostscript for substandard quality
though. Am I the first person on the planet who has conceived of comparing gs
postscript to postscript generated by other means for the purpose of determining
quality? We have 2 different tools that should produce the same thing. One is
not even close to the other. That's the one to fix. It's as simple as that.

Will this patch show up in an official release of GS ?

Created attachment 86526 [details]
Patch for ESP GhostScript 7.05.5 (current CVS)

I have created now a version of the "dictfull.diff" patch for the current CVS of
ESP GhostScript, it probably also works with GNU GhostScript 7.05.

I didn't find any real problem with GhostScript, I can display all four files
attached to this bug with ESP GhostScript 7.05.5 with and without patch. I can
also convert them to level 1 with or without patch, using the command line

cat file.ps | gs -q -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=pswrite
-dLanguageLevel=1 -sOutputFile=- - >testfile

and I can always display the resulting "testfile" files with gv (using ESP
GhostScript 7.05.5). I have no Level 1 PostScript printer to check whether the
resulting files are really level 1. So I want to ask you to try the following:

Print with the following command line all four attached files:

cat file.ps | gs -q -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=pswrite
-dLanguageLevel=1 -sOutputFile=- - > /dev/lp0

(I assume that the printer is on the first parallel port). Does this work? What
does the printer do?

If it works (please tell, if so), there must be a problem with the
spooler/Foomatic configuration. To find it, edit /usr/sbin/lpdomatic (or
whereever the "lpdomatic" filter script is under Red Hat) replacing "my
$debug=0;" with "my $debug=1;" and then send the job again (using the queue
which you have set up with the driver with Level2 -> Level1 conversion, check
whether the "Perfilter" option is really set to "Level1") and then attach your
/tmp/prnlog or /tmp/lpdomatic.log file to this bug. Then I could see whether
there is a problem with lpdomatic or the driver data.

The bad quality of the Mozilla output I would consider to be another bug which
is independent of the PostScript-Level-1-not-being-printed bug, so a new bug (a
Mozilla bug) should be filed to treat this. These should perhaps be better
placed on the Bugzilla of Mozilla, because it does not only affect Red Hat Linux.

ghostscript-7.05-25, which will appear in rawhide shortly, has this patch applied.

Unfortunately my schedule is completely overloaded right now so I won't be able
to follow up on the latest suggestions until 11/28. I have downloaded the
7.05-24 source, it built cleanly but doesn't execute ("Unrecoverable error:
undefinedfilename in metrics2.ps"). It sure would be nice if the source rpms
contained source code with the patches already applied so that an immediate make
produces the same binary as which is contained in the binary rpm. I'm not sure
how someone should decide which patches to apply and in what order. Once I can
build a functional binary I'll add the patch. Before that I'll try Till's
recommendations. As for our gracious hosts they're probably correct to close
this for now. I'll definitely try out gs 7.05-25, but we might have this
resolved before then. I'll correspond with Till directly regarding the follow-up
to his recommendations. Thanks to all for helping to resolve this and happy
holidays.

I have applied the patch to the CVS of ESP GhostScript now, so ESP GhostScript
7.05.6 will be the first GhostScript release with this patch applied.