Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Jul 1996 17:30:26 GMT
From:      James Raynard <fports@jraynard.demon.co.uk>
To:        andreas@klemm.gtn.com
Cc:        ports@freebsd.org, se@freebsd.org
Subject:   Re: need some help with ghostscript4.0 port
Message-ID:  <199607011730.RAA01242@jraynard.demon.co.uk>
In-Reply-To: <Pine.BSI.3.94.960701074713.10690A-100000@klemm.gtn.com> (message from Andreas Klemm on Mon, 1 Jul 1996 07:48:29 %2B0200 (MET DST))

next in thread | previous in thread | raw e-mail | index | archive | help
> Send me a patch, I'll put it in the ports collection.
> And I'll report it to Alladdin.

Thanks! The problem is that I have a HP DeskJet520, for which DJ500 is
presumably the correct driver. However, this results in a binary
(compressed PCL?) version of the file being printed whenever I use it
to try and print a PostScript file.  The following patch allows the
file to be printed correctly:-

--- gdevdjet.c.orig     Mon Jul  1 15:47:06 1996
+++ gdevdjet.c  Mon Jul  1 15:48:13 1996
@@ -282,7 +282,7 @@
 /* The DeskJet500 can compress (modes 2&3) */
 private int
 djet500_print_page(gx_device_printer *pdev, FILE *prn_stream)
-{      return hpjet_print_page(pdev, prn_stream, DJ500, 300, mode_3,
+{      return hpjet_print_page(pdev, prn_stream, DJ500, 300, mode_2,
                "\033&k1W");
 }
 /* The LaserJet series II can't compress */

HP apparently decided to remove this undocumented feature(*), so perhaps
the comment above it should be amended as well.

However, there's one slight problem left after the above patch. I can
prepare .ps files, using LaTeX and dvips, and view them under
ghostview with no problems. However, when I try and print them, it
always prints

Error: /syntaxerror in -file-
                             Operand stack:

                                           Execution stack:
                                                             %interp_exit   ()

instead of the final page. Any ideas on how to tackle this? (I can
print other people's .ps files with no problems, so presumably it's a
dvips problem? Or pilot error??)

(*) As manufacturers have a nasty tendency to do this kind of thing,
wouldn't it be better to avoid relying on undocumented features? At
the very least, any dependence on such features such be clearly stated
in the documentation, instead of being tucked away in a comment. I
wasted a lot of time trying to track this down...

-- 
James Raynard, Edinburgh, Scotland
james@jraynard.demon.co.uk
http://www.freebsd.org/~jraynard/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607011730.RAA01242>