HDTenEightyP/NetNews huggingface dataset:
From: rose@t524i5.telematik.informatik.uni-karlsruhe.de (Ortwin Rose)
Subject: g++ and glibc
Organization: /usr/users/rose/.organization
Distribution: gnu
Date: Mon, 5 Oct 1992 20:23:35 GMT

Has anybody managed to get a 'pure' GNU-based system (i.e.
using glibc-1.05 for all C-functions, and libg++-2.1 for
other stuff)? I've tried to combine both, but its really
a nasty thing, since both libs contain at least partially
the same functions with different prototypes!

Any help appreciated!

Regards

-- O. Rose
   University of Karlsruhe
   Institute of Telematics

Newsgroups: gnu.groff.bug
From: imram@ruby.UUCP (Imram Engineering Corporation)
Subject: Bug in AT&T netlib distribution for PIC
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 20:21:06 GMT

			   Groff Bug Report

GROFF VERSION:
1.06

MACHINE:
Sun Sparc1

OS:
SunOS 4.1.2b

COMPILER:
gcc-2.2.2 

INPUT FILES: 
-NA-

COMMAND LINE:
-NA-

DESCRIPTION OF INCORRECT BEHAVIOUR:
Subject: Bug in AT&T netlib distribution for PIC 

There is a bug in your distribution of '116 from research/cstr'.
My request was based on the following (from gpic man page):

     AT&T Bell Laboratories, Computing Science  Technical  Report
     No. 116,  PIC  - A Graphics Language for Typesetting.  (This
     can   be   obtained   by   sending   a   mail   message   to
     netlib@research.att.com       with       a      body      of
     `send 116 from research/cstr'.)

It comes in two shar parts.  Although the shar program re-concatenates
the two parts, the result is not successful.  Only part one prints to
page 18 (first 20 pages), and then part two is lost.

On a postscript viewer, part two reappears on page 21 but the postscript
printer does not print anything beyond page 18.  On viewer, parts of 
page 18 and all of 19, 20 are lost.

There is no obvious problem in the postscript source.

It is hard to test because everytime I run the job I get the same
20 pages of output.

Could you please correct this distribution and email me?

FYI, here are the checksums and wordcounts of the files:
For shar files, mail header removed to line "#!/bin/sh",
blank line at end remains:

sum pic116*
05286   127 pic116
19143    97 pic116.shar1
07341    31 pic116.shar2

wc pic116*
    5355   27520  129254 pic116
    4020   20983   98609 pic116.shar1
    1359    6620   31225 pic116.shar2
   10734   55123  259088 total


Suggestions for fix:
1) Test the distribution yourself before posting.
2) Send files with a checksum
3) Do not split file

Steve Davidson
steved@cfcl.com
415-355-6535


Newsgroups: gnu.groff.bug
From: stevedav@netcom.com (Steve Davidson)
Subject: Problem in compiling on Sun sparc
Keywords: groff compile bug
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Thu, 1 Oct 1992 23:23:25 GMT

                           Groff Bug Report

GROFF VERSION:
1.05

MACHINE:
Sun 4/60 (Sparc 1)

OS:
4.1.2b

COMPILER:
gcc/g++ 2.2.2

INPUT FILES: 
makefile and groff source 

COMMAND LINE:
make

DESCRIPTION OF INCORRECT BEHAVIOUR:
Here is the output of a simple 'make' verbatum:
(This is the 2nd time make was run; a few targets compiled in the
first make).

======================== OUTPUT STARTS HERE ===============================
47% make
Making all in lib
g++ -c -I. -g -O             -DWAIT_COREDUMP_0200 -DNO_SYS_WAIT_H errarg.c
errarg.c: In method `errarg::errarg (const char *)':
errarg.c:26: assignment between incompatible pointer types
*** Error code 1
make: Fatal error: Command failed for target `errarg.o'
Current working directory /u/src/groff-1.05/lib
*** Error code 1
make: Fatal error: Command failed for target `lib'


SUGGESTED FIX [optional]:
Can you tell me how to get this to compile?

steved@cfcl.com
Steve Davidson


Newsgroups: gnu.groff.bug
From: stevedav@netcom.com (Steve Davidson)
Subject: Postscript and TIFF capabilities with troff/groff
Keywords: postscript troff groff text TIFF
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Thu, 1 Oct 1992 23:20:56 GMT

Feature sought:
I need to combine postscript capabilities with troff/groff.

The task is to produce documents with shading, "reverse video",
bubbles/ellipsis (instead of rectangles), etc.

I also must incorporate TIFF images into documents.

This will produce professional-looking documents such as invoices,
letters, envelopes, work-tickets, etc.

Can anyone suggest software that can do this?

I prefer Gnu-like free software.

(I will post results to the net if anyone shows interest).

Steve Davidson
steved@cfcl.com


Newsgroups: gnu.groff.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: eqn man page uses .Tp without defining it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 17:38:49 GMT

GROFF VERSION: 1.06

MACHINE: Sun Sparcstation 1

OS: SunOS 4.1.2

COMPILER: GCC 2.2.2

INPUT FILES: eqn/eqn.man

COMMAND LINE: groff -man -ww

DESCRIPTION OF INCORRECT BEHAVIOUR:
	<standard input>:821: warning: `Tp' not defined

SUGGESTED FIX:
===================================================================
RCS file: eqn/eqn.man,v
retrieving revision 1.6
diff -c -r1.6 eqn/eqn.man
*** eqn/eqn.man	1992/08/27 11:05:37	1.6
--- eqn/eqn.man	1992/10/05 17:34:11
***************
*** 1,4 ****
--- 1,8 ----
  .\" -*- nroff -*-
+ .de Tp
+ .ie \\n(.$=0:((0\\$1)*2u>(\\n(.lu-\\n(.iu)) .TP
+ .el .TP "\\$1"
+ ..
  .ie \n(.V<\n(.v .ds tx T\h'-.1667m'\v'.224m'E\v'-.224m'\h'-.125m'X
  .el .ds tx TeX
  .\" The BSD man macros can't handle " in arguments to font change macros,

Newsgroups: gnu.groff.bug
From: 8004slb@vmsf.csd.mu.edu (Sandy Berger)
Subject: VMS version of groff?
Reply-To: 8004slb@vmsf.csd.mu.edu
Organization: Marquette University - Computer Services
Distribution: gnu
Date: Sat, 26 Sep 1992 21:06:10 GMT

Is there a VMS version of groff available?

------------------------------------------------------------------------------

Sanford L. Berger            Sr. Systems Administrator
Marquette University         Central Computer Operations
Computer Services Division

INTERNET: 8004SLB@VMS.CSD.MU.EDU
BITNET:   8004SLB%VMS.CSD.MU.EDU@CUNYVM

Newsgroups: gnu.groff.bug
From: kk@hpkronos.hpl.hp.com (Konstantinos Konstantinides)
Subject: gxditview
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 04:44:13 GMT

groff 1.06 on an HP9000/s700

groff does not work with -X option (gxditview has been recompiled)

[107]#  groff -X  troff/troff.man
Usage: gxditview [-fg <color>] [-bg <color>]
       [-bd <color>] [-bw <pixels>] [-help]
       [-display displayname] [-geometry geom]
       [-page <page-number>] [-backing <backing-store>]
       [-resolution <res>] [-print <command>]
       [filename]

[108]#  groff -V  -X -man  troff/troff.man
gtroff -man -r.X=1 -Tps troff/troff.man | gxditview -title troff/troff.man -xrm
'*iconName:troff/troff.man' -filename '| groff -Z -V -X -man troff/troff.man' -p
rintCommand 'grops | lp -dpsjet -oraw' -

Any other way gxditview might work?
Thanks
K. Konstantinides
kk@hpkronos.hpl.hp.com

Newsgroups: gnu.groff.bug
From: imram@ruby.UUCP (Imram Engineering Corporation)
Subject: groff1.05 compilation failure
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 20:52:03 GMT

			   Groff Bug Report

GROFF VERSION:
1.05

MACHINE:
Sun 4/60 (Sparc 1)

OS:
4.1.2b

COMPILER:
gcc/g++ 2.2.2

INPUT FILES: 
makefile and groff source 

COMMAND LINE:
make

DESCRIPTION OF INCORRECT BEHAVIOUR:
Here is the output of a simple 'make' verbatum:
(This is the 2nd time make was run; a few targets compiled in the
first make).

======================== OUTPUT STARTS HERE ===============================
47% make
Making all in lib
g++ -c -I. -g -O             -DWAIT_COREDUMP_0200 -DNO_SYS_WAIT_H errarg.c
errarg.c: In method `errarg::errarg (const char *)':
errarg.c:26: assignment between incompatible pointer types
*** Error code 1
make: Fatal error: Command failed for target `errarg.o'
Current working directory /u/src/groff-1.05/lib
*** Error code 1
make: Fatal error: Command failed for target `lib'


SUGGESTED FIX [optional]:
Can you tell me how to get this to compile?


Newsgroups: gnu.ghostscript.bug
From: ghost@aladdin.COM (L. Peter Deutsch)
Subject: Re: Problem with TeX
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 03:16:48 GMT

>From ghost  Thu Oct  1 20:06 PDT 1992 remote from aladdin
Date: Thu, 1 Oct 92 20:06:08 PDT
From: ghost@aladdin.com (L. Peter Deutsch)
Subject: Re: Problem with TeX
To: drector@math.uci.edu
cc: bug-ghostscript

Re <9210011722.AA14286@cookie-crisp>
<199209301826.AA10021@news.service.uci.edu>:

> >I would like to use ghostscript to preview TeX output with ps graphics
> >inclusions.  When I attempt to view a TeX output file I get an
> >insufficient memory message.  I am using gs252 on an msdos '486
> >machine, 16mb ram, with windows 3.0.  I get the same result with
> >gs386.exe, gswin.exe, and gs.exe (expected for 640k version).
> >My TeX ps files are produced by ptips (Personal TeX version of dvips).
> 
> >Is there any way to get ghostscript to use more memory?
> 
> I have some more information (having learned far more about postscript
> than I wanted to):
> 
> The source of the problem was an "enhancement" Personal Tex Inc. added
> to its ps driver, but it points up a ghostscript departure from level 1
> practice and level two specs.
> 
> Before processing, the PTI postscript file checks to see that free VM
> (maximum - used) is greater that 144000--I presume this is to detect a
> failed previous job on the printer.  This works on most printers since
> most Level 1 devices provide 240000 bytes VM (Appendix B, Postscript
> Language Reference Manual (2nd ed.), Adobe Systems Inc.).  Ghostscript
> (MSDOS versions) starts up with a VM limit of 105000.  In addition, I
> have not been able to find that Ghostscript implements Level 2
> interpreter parameters, such as MaxLocalVM (Appendix C, ibid.).

Not yet.  Ghostscript 2.6 will support a few of them, but of course
only if the Level 2 features are included in the configuration (which
they normally are for gs386.exe, but not for gs.exe or gswin.exe
because they take up so much space).

What do you think the semantics of MaxLocalVM should be?  If you set
it, should Ghostscript immediately attempt to acquire that much
memory? 

> Question (again): is there any way to force Ghostscript to allocate
> more VM before running a program.

Well, not really.  Ghostscript is designed to be a "good citizen" on
small machines, and only allocates VM (by calling the operating
system) when it needs it: you will see the "maximum VM" value rise in
the course of a job.  You can force Ghostscript to acquire and then
release a lot of VM by doing something like
	100 { 500 array } repeat
	100 { pop } repeat
which acquires and releases 400K.  (Because of the way Ghostscript's
memory manager works, doing this with a single large array won't have
the desired effect, and may cause a limitcheck.)

L. Peter Deutsch :: Aladdin Enterprises :: P.O. box 60264, Palo Alto, CA 94306
ghost@aladdin.com, ...decwrl!aladdin!ghost ; voice 415-322-0103 ; fax 322-1734
    "Implementation is the sincerest form of flattery."    new--->^^^^^^^^^^^^




Newsgroups: gnu.ghostscript.bug
From: brian@kokom.mit.edu (Brian McAllister)
Subject: Unaligned access errors in mem_get_bits()
Organization: Bates LINAC, MIT
Distribution: gnu
Date: Fri, 25 Sep 1992 19:58:44 GMT

Ghostscript 2.5.2,  Ultrix 4.2, DS5000/200

I am getting "unaligned access errors" from gs.  I have traced the
problem to the function mem_get_bits().  Here is the call trace:
	main				gs.c:190
	(.....)
	gs_interpret			interp.c:182
	interp				interp.c:524
	zoutputpage			zdevice.c:169
	gs_output_page			gsdevice.c:88
	gdev_prn_output_page		gdevprn.c:238
	ln03_print_page			gdevln03.c:80
	sixel_printpage			gdevln03.c:146
	gdev_prn_copy_scan_lines	gdevprn.c:369
	gdev_prn_get_bits		gdevprn.c
	mem_get_bits			gdevmem1.c:180

The problem seems to be that when gdev_prn_copy_scan_lines() calls
gdev_prn_get_bits(), the "pad" argument is 0.  mem_get_bits() computes
the bytes_per_line using gs_device_raster(), and gets an odd number
(319 in this case), as its pad_to_word argument is 0.  This causes
memswab2() to be called with an odd address, leading to the unaligned
access errors.  The comment on memswab2() says "src and dest must be
16-bit aligned".  In this case, they are not.

I do not get the errors if I specify the laserjet driver, or use an X
window for display.  However, I don't see anything in
gdev_prn_copy_scan_lines() that allows it to change behavior (pad the
bytes_per_line) based on the output device.

As far as I can recall, gs2.4.1 did not exhibit this problem, and
gs2.5 did.

--
----
Brian McAllister       Internet: mcallister@mit.edu
                         BITNET: BRIAN@MITBATES

Newsgroups: gnu.ghostscript.bug
From: ghost@aladdin.COM (L. Peter Deutsch)
Subject: Garbled output with Tseng driver
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 00:54:49 GMT

A user writes:

> When fed PS output from the MS Windows PSCRIPT.DRV postscript driver
> version 3.53, and using the Tseng output device, gs386.exe from the gs
> 2.5.2 distribution produces strongly skewed and illegible displays that
> use only about the top 60% of the screen.  This appears to happen
> regardless of the originating Windows program -- I get the same
> behaviour when output is generated by Windows Write, WordPerfect for
> Windows, and other programs.  The problem exists regardless of whether
> the -g switch is used, and regardless of its setting if it is used.
> 
> gswin.exe is able to handle these same files correctly.
> 
> I am able to view other PS files without any problem, using both gs386
> and gswin.

This is a bug resulting from the "new and improved" handling of paper
size in Ghostscript 2.5.2.  It only affects SuperVGA drivers in
gs.exe and gs386.exe, not gswin.exe, and it doesn't affect the VESA
driver in gs.exe.  To fix it, move the statement
	fb_dev->raster = fb_dev->width;
from line 76 of gdevsvga.c (i.e., the first line of the
svga_find_mode procedure) to just above the
			return 0;
which is currently line 83.

A workaround that doesn't require recompiling Ghostscript is to find
the definition of the .setpagesize procedure in gs_statd.ps (lines
149 through 155) and replace it with the following:
	/.setpagesize {pop pop} bind def
This will cause all pages to be clipped as though they were U.S.
letter-size, so this workaround should not be used if you are going
to be printing on A4 paper, for example.

L. Peter Deutsch :: Aladdin Enterprises :: P.O. box 60264, Palo Alto, CA 94306
ghost@aladdin.com, ...decwrl!aladdin!ghost ; voice 415-322-0103 ; fax 322-1734
    "Implementation is the sincerest form of flattery."    new--->^^^^^^^^^^^^




Newsgroups: gnu.ghostscript.bug
From: pm860605@longs.lance.colostate.edu (Peter Mckinney)
Subject: Re: Problem with Gswin.exe 2.5.2 for Windows 3.1
Organization: Colorado State U. Engineering College, Ft. Collins, CO 80523
Distribution: gnu
Date: Mon, 28 Sep 1992 17:37:13 GMT

In article <Sep28.172037.59259@yuma.ACNS.ColoState.EDU>, pm860605@longs.lance.colostate.edu (Peter Mckinney) writes:
|> In article <1a5imiINNeov@usenet.INS.CWRU.Edu>, bz223@cleveland.FReenet.EDU (Danny Guy Frezza) writes:
|> |> As the title suggest, since I loaded Gswin.exe 2.5.2 and the accompanied
|> |> files for it, when I attempt to run it in Windows 3.1 (Enhanced mode),
|> |> it appears to start loading for a moment and then flips right out. Tried
|> |> loading several times, but for a brief moment, it says something about not
|> |> initializing for 256? Now, Gswin.exe for 2.5.1 worked with its accompanied
|> |> files, but this version won't. My windows setup is for 800x600x16.
|> |> Can anyone suggest what is suddenly happening in 2.5.2 that didn't in 2.5.1?
|> 
|> Try changing the string near the top of the gs_init.ps file that
|> reads "252" to "251".  I think the GSWIN.EXE binary is still looking
|> for a version 2.5.1 init file.  This fixed the problem for me.  Note,
|> howver that this will create the same problem for the DOS binaries
|> GS386.EXE, etc. because they correctly look for the "252" string.
 
According to a post on comp.binaries.ibm.pc.archives
dated Mon, 28 Sep 92 00:09:12 GMT-)1:44, a corrected
archive of the GSWIN.EXE binary has been upoaded to simtel20.

	- Pete McKinney
____________________________________________________________________________
| Peter J. McKinney                     pm860605@longs.LANCE.ColoState.Edu |
| Electrohydrodynamic Laboratory                                           |
| Fluid Mechanics and Wind Engineering Program                             |
| Civil Engineering Department                                             |
| Colorado State University                                                |
----------------------------------------------------------------------------

Newsgroups: gnu.ghostscript.bug
From: ghost@aladdin.COM (L. Peter Deutsch)
Subject: Re: GS252WIN not 2.5.2 Compatible
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Sep 1992 16:41:37 GMT

Re <9209280154.AA03364@cookie-crisp>
<Sep25.192314.43136@yuma.ACNS.ColoState.EDU>:

> The program GSWIN.EXE contained in the archive GS252WIN.ZIP on Simtel and
> mirror sites is not compatible with the Ghostscript 2.5.2 release.  It
> expects the file gs_init.ps to have a reference to 2.5.1 in it and therefore
> must be from the 2.5.1 release.  It will run properly if the "252" string
> near the top of the gs_init.ps file is changed to "251".  The DOS versions
> require the string to be "252", however.

Ghostscript is released as a unit; the executables, gs_init.ps, and
the other gs_*.ps files work together.  That is why I added a
specific test in gs_init.ps to make sure the executable and
gs_init.ps were compatible with each other.  If the mirror sites are
only copying part of the distribution, they are doing the wrong
thing: take this up with them.  I won't even answer bug reports from
users who have patched configurations together out of files from
different releases.

L. Peter Deutsch :: Aladdin Enterprises :: P.O. box 60264, Palo Alto, CA 94306
ghost@aladdin.com, ...decwrl!aladdin!ghost ; voice 415-322-0103 ; fax 322-1734
    "Implementation is the sincerest form of flattery."    new--->^^^^^^^^^^^^




Newsgroups: gnu.ghostscript.bug
From: ghost@aladdin.COM (L. Peter Deutsch)
Subject: man page for Ghostscript
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 27 Sep 1992 18:45:22 GMT

Over time, I've received at least 4 different suggested `man' pages
for Ghostscript.  I've also received advice from FSF not to spend
time maintaining a man page, but to maintain documentation in texinfo
form instead.

Since I don't have ready access to Unix systems, maintaining texinfo
documentation is out of the question for me.  Since (I believe) many
Unix sites do not run texinfo, I feel it is important to distribute a
man page.  However, I don't have ready access to troff for this
purpose either.

I would like to ask for a volunteer to take responsibility for
texinfo and/or man page documentation for Ghostscript.  What this
would involve is updating this documentation during the beta test
period for each release, and sending it to me so I could include it
in the final fileset.  I would continue to supply the plain-text
documentation as it currently exists.  The key word here is
`responsibility': please only volunteer if you have the time to do
this consistently.

Let me know if you'd like to help make Ghostscript more useful by
doing this.  The next release isn't due out till around January, so
there's no big hurry. Thanks.

L. Peter Deutsch :: Aladdin Enterprises :: P.O. box 60264, Palo Alto, CA 94306
ghost@aladdin.com, ...decwrl!aladdin!ghost ; voice 415-322-0103 ; fax 322-1734
    "Implementation is the sincerest form of flattery."    new--->^^^^^^^^^^^^




Newsgroups: gnu.ghostscript.bug
From: ye20@gec-mrc.co.UK (ye20)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 15:27:37 GMT

Problem printing dithered images on an HP Paintjet with GS2.5.2

Having recently installed Ghostscript 2.5.2 on our Sun IPC, upgrading from
version 2.4, I find that the output quality of dithered colour images to 
our HP Paintjet/DEC LJ250 is vastly inferior to that of the previous release.
The images are much coarser and there is a pronounced chequerboard effect 
over large areas of solid colour. Most of the images being printed are shaded
solid models from CAD systems captured from the Sun colour screen.

Are other users experiencing this this problem and can anything be altered
to mimimise these effects?

Any help would be appreciated

---------------------------------------------------------------------------
John Pomeroy, Eng. Research Lab. | Tel: +44 245 73331 x 3305
GEC-Marconi Research Centre      | Fax: +44 245 75244  Telex 995016 GECRES G 
GEC-Marconi Ltd, Great Baddow    | uucp: <world>!mcvax!ukc!gec-mrc!pomeroy
Chelmsford, Essex. UK  CM2 8HN   | Other: pomeroy@uk.co.gec-mrc
---------------------------------------------------------------------------



Newsgroups: gnu.ghostscript.bug
From: markh@analogy.COM (Mark Holm)
Subject: Using Ghostscript with netatalk and Mac's?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 18:12:42 GMT

If I have posted this incorrectly, I apologize. My news poster is broken ...

I Downloaded a copy of Ghostscript 2.5 and built it on a Sun running 4.1.2
to drive a HP Paintjet that I had lying around. Works great! Good job guys!

Now for the hitch. The Mac users found out we had a "Color" printer
available and now want to use it as well. So ... I down loaded a copy of
netatalk 2.2.1 and built, configured and installed it, and everything works
.. except it won't print anything from the Macs. Files gfo into the
spooler properly, but nothing comes out the printer. I stoped the spooler
and grabbed one of the data files and fed it to gs and it choked with the
following messages:

> Initializing... done.
> Loading Times-Roman font from /usr/local/lib/ghostscript/fonts/ptmr.gsf...
> 686416 669172 1 done.
> Loading Courier font from /usr/local/lib/ghostscript/fonts/ncrr.gsf...
> 746416 725458 1 done.
> Loading Helvetica font from /usr/local/lib/ghostscript/fonts/phvr.gsf...
> 766416 764096 1 done.
> %%[|0|]%%Error: /invalidfont in -dicttype-
> Operand stack:
>     272  14.9998  0  0  0  1  0  0  0  0  1  1  null  null  0  0  0  1  0
> 0  1  0  0  1  0  0  1  0  0  1.09596  0  -0  1.09596  32.8787  32.9746
> /Helvetica  -dicttype-  /Helvetica
> Execution stack:
>     %interp_exit    --nostringval--  --nostringval--  false
> --nostringval--  --nostringval--  false  --nostringval--  --nostringval--
> --nostringval--  false  --nostringval--  --nostringval--  --nostringval--
> --nostringval--  --nostringval--
> Dictionary stack:
>     461/479  14/200  238/270  11/25  461/479  12/12
> Ghostscript 2.5 (8/18/92)
>   Copyright (C) 1990, 1992 Aladdin Enterprises, Menlo Park, CA.
>   All rights reserved.
> Distributed by Free Software Foundation, Inc.
> Ghostscript comes with NO WARRANTY: see the file LICENSE for details.
> GS<38>

I thought possibly it was because I had a bad procset file, but after
downloading macps and using prepfix on it. I still get the same error. Can
somebody give me a pointer on what I am doing wrong? Or, better yet tell me
how to do this correctly?

Any help would be appreciated. Please reply back directly to me as I do not
regulary read this newsgroup.

Again, Good Job guys you have made a really neat program! It finally made
my deskjet at home a viable UNIX printer for me.

===========================================================================
Mark Holm                                           markh@analogy.com  -or-
Analogy                                           ..sun!nosun!analogy!markh
P.O. Box 1669                                           Phone (503)626-9700
Beaverton, Oregon 97075-1669				Fax   (503)643-3361


Newsgroups: gnu.ghostscript.bug