HDTenEightyP/NetNews huggingface dataset:
From: amillar@bolis.sf-bay.ORG (Alan Millar)
Subject: Problem liking GS2.5 on MSDos
Organization: The Bolis Group, San Jose, CA
Distribution: gnu
Date: Sun, 13 Sep 1992 20:42:56 GMT

Hi-

I am having a problem with GS 2.5 on MS-Dos.  I am using Turbo C++ 1.01
to compile/link.  I have had no problems compiling and linking 2.4.1

During linking, I get the error message:

  Error: Fixup overflow in module GSSTATE.C at GSSTATE_TEXT:0C04, target 
    = _TEXT:0000

This message repeats about ten times with something different for the 0C04
part.  It happens with TCBPLUS.MAK and TURBOC.MAK  I'm not changing 
anything in the make file.  Honest.

The manual says that this is usually cause by a mis-match in memory models.

Has anyone else come across this?  Has anyone successfully compiled it 
with TurboC++?  Did it require any tweaking to the make file?

I'd appreciate any tips.  Thanks.

- Alan


----             email:                                  ,,,,  
Alan Millar       amillar@bolis.SF-Bay.org            __oo  \  
    (Remember: only YOU can prevent bang paths)         =___/  
But Moses said "Oh, Lord, please send someone else to do it." -Exo. 4:13
From: rjl@fawlty7.eng.monash.edu.au (Russell Lang)
Newsgroups: gnu.ghostscript.bug
Subject: Re: output of dvips too large in gs2.5
Date: 11 Sep 92 06:59:12 GMT
Distribution: gnu
Organization: Monash University, Melb., Australia.

iigsa01@convex.zdv.uni-tuebingen.de (Andreas Schilling) writes:
>If I replace all occurences of a4 (my paper size, works exactly the same with
>letter) with a1234 in my PS file, then the scaling is fine. Maybe dvips uses
>a4 in a different way than GS, or maybe setting the paper size in GS uses the
>horizontal size of the screen and the document to fit the size???

It is a bug in gs 2.5.  Should be fixed in the next version of gs.
It is doing exactly what you think - matching the width of the paper
to the width of the screen.

If you have a compiler and the time to recompile ghostscript,
change line 369 of gsdevice.c from:
    double ratio = max(width_ratio, height_ratio);
to
    double ratio = min(width_ratio, height_ratio);
-- 
Russell Lang   Email: rjl@fawlty4.eng.monash.edu.au   Phone: (03) 565 3460
Department of Electrical and Computer Systems Engineering
Monash University, Australia
Newsgroups: gnu.ghostscript.bug
From: medin@cod.nosc.mil (Ted Medin)
Subject: One more question about ghostscript - hp paintjet
Keywords: hp-paintjet
Organization: Naval Ocean Systems Center, San Diego
Distribution: gnu
Date: Thu, 10 Sep 1992 16:13:05 GMT

 Is the hp-paintjet supported? If so how about color?
From: tunxis@netcom.com (Gary A. Gorgen)
Newsgroups: gnu.ghostscript.bug
Subject: Re: Compile Errors in Ghostscript 2.5
Date: 11 Sep 92 14:41:38 GMT
Distribution: gnu
Organization: Tunxis Design Inc. (408-749-9463)

lambda@sbcs.sunysb.edu (Del Lamb), <1992Sep10.024120.11467@sbcs.sunysb.edu>
Writes:

>Hello, I'm a newcomer to this group and Ghostscript, so forgive any
>unintention violations of netiquette.  I'm trying to compile GS 2.5
>on a i486 running System V, R4 V3 (Consensys V4, rel 1.3) and I have
>a nasty (for me), but probably simple, compile problem.
>
>In the compile for iinit.c, the following error messages occur:
>[...]
>        ./ccgs "cc  -O  -DSVR4" iinit.c
>"iinit.c", line 159: left operand must be modifiable lvalue: op "="
>"iinit.c", line 159: operand must be modifiable lvalue: op "++"
>"iinit.c", line 175: left operand must be modifiable lvalue: op "="
>"iinit.c", line 175: operand must be modifiable lvalue: op "++"
>"iinit.c", line 186: left operand must be modifiable lvalue: op "="
>"iinit.c", line 186: operand must be modifiable lvalue: op "++"
>"iinit.c", line 201: left operand must be modifiable lvalue: op "="
>mv: cannot access _temp_3084.o
>[...]
>        ./ccgs "cc  -O  -DSVR4" zprops.c
>"zprops.c", line 177: left operand must be modifiable lvalue: op "+="
>mv: cannot access _temp_3094.o
>[...]


Make these changes to ostack.h & opdef.h
GS 2.5 will compile OK, on SVR4. Ignore the compiler warnings.
If GS doesn't run, then recompile without the -O flag.
There are several optimizer bugs in the stock SVR4 compiler, which may not
be fixed in your compiler.



opdef.h
--------------------------------------------------
60c60
< typedef const op_def _ds *op_def_ptr;
---
> typedef /*const*/ op_def _ds *op_def_ptr;
--------------------------------------------------

ostack.h
--------------------------------------------------
30c30
< typedef const ref _ds *const_os_ptr;
---
> typedef /*const*/ ref _ds *const_os_ptr;
--------------------------------------------------
Hope this helps.

Gary.
-- 



-- 
Gary A. Gorgen      | "From ideas to PRODUCTS"
tunxis@netcom.com   | Tunxis Design Inc.
                    | 422 S. Murphy, Sunnyvale Ca. (408) 749-9463
Newsgroups: gnu.ghostscript.bug
From: ghost@aladdin.COM (L. Peter Deutsch)
Subject: Setting device props in Ghostscript 2.5
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 04:14:20 GMT

In <9208310527.AA10317@cookie-crisp>
<9208310336.AA05738@kodiak.cs.caltech.edu>, Andy Fyfe asks why
setting device properties (specifically, BufferSpace and MaxBitmap)
in a separate file using putdeviceprops doesn't seem to take effect,
and why PBM output with and without using a band file seems to differ
slightly.

Setting device properties doesn't have the proper effect because of a
bug in Ghostscript 2.5, which will be corrected in 2.5.1.  Note,
however, that Ghostscript always allocates the amount of buffer
memory implied by command line parameters; a subsequent
putdeviceprops may free the memory and reallocate it with a different
size, but if the initial allocation fails, Ghostscript will signal a
VMerror and stop.  Fyfe suggests using a little prefix file that
invokes putdeviceprops, but a better way to handle this is with
Ghostscript's new ability (as of 2.5) to interpret a file as
containing additional switches.  For example, if the file band1
contains
	-sBufferSpace=400000 -sMaxBitmap=400000
then
	gs @band1 file.ps
is equivalent to
	gs -sBufferSpace=400000 -sMaxBitmap=400000 file.ps
Of course the customary Unix shell provides equivalent facilities,
but the DOS shell does not.

As for the other question, the output differs because in one case,
unused bits in the last byte (if the width is not a multiple of 8
bits) are always zero, and in the other case, they may contain
garbage.

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: Re: Ghostscript 2.5.1 is released
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 14:25:39 GMT

Re <92Sep14.082820mesz.102870@hphalle0.informatik.tu-muenchen.de>:

> The docs of gs 2.5.1 mention some fonts in Type 1 fonts, i.e. Courier,
> Utopia and Cyrillic. However, the package does only contain .gsf fonts.
> I know this is a bit off-way, but why aren't the fonts included in their
> original Type 1 format too?

.gsf *IS* Type 1 format.  There is no standard file suffix for Type
1.  Some systems use .ps, some use .pfa.  I decided to use .gsf;
probably that has caused more confusion than it was worth.

> If they have been donated in this format by
> IBM or Adobe, shouldn't they be included unchanged too?

I removed the eexec encoding from the donated fonts so they would
load faster, and eliminated some mysterious characters.  That's all.

> Especially I was
> interested in the cyrillic font in type 1 format. Where can I get the
> original font in Type 1 format?

The Cyrillic fonts are shareware from some place in Oregon.  They are
in their original format.

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: dww2@po.cwru.edu (David W. Woodward)
Subject: Ghostscript 2.5/Win Problem
Reply-To: dww2@po.cwru.edu (David W. Woodward)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Distribution: gnu
Date: Fri, 4 Sep 1992 22:41:05 GMT

GS 2.5 is the first version I have ever used, so this could be just basic
stupidity on my part....

I installed everything from simtel (gswin, gsbase, and gs386), but no
fonts.  (I am trying to read the manual pages from the Microsoft WIn NT
SDK.)  I viewed it, and all the fonts were substituted with Ugly--really
hard to read, but there.  Then, I installed all of the fonts from
ghostscript-fonts-2.5 from ai.prep.mit.edu.  After installing a few from
ATM and making some aliases in the font list, I realized the large page
headings (chapter headings) and section heading were not showing up.  I
THINK they are in helvetica.  The regular (times roman) stuff shows up, but
the headings don't.  They DID when all there was was ugly, but as soon as I
installed the others, they didn't (this was even BEOFRE I made changed to
fontmap.)

Help?

Dave

I haven't tried gs386--the archive at simtel is corrupted, and I haven't
gotten around to getting it from somwhere else yet.  This is all with
gswin.

Thanks again!

Newsgroups: gnu.ghostscript.bug
From: patrice@cs.sfu.ca (Patrice Belleville)
Subject: Problem with pathforall ( + fix )
Followup-To: gnu.ghostscript.bug
Summary: bug and a way to fix it
Keywords: pathforall, bug
Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada
Distribution: gnu
Date: Wed, 9 Sep 1992 03:47:43 GMT

	There  seems  to be a bug  in  the  implementation  of the pathforall
operator [for both gs2.4.1 and gs2.5].  According  to the PostScript Language
Reference  Manual, second  edition  : "If any  of  the  procedures change the
current path, such changes do not alter the behavior of pathforall" [p462].

	That is not the case right now. If the  procedures invoked during the
execution of the pathforall create a  path that  is longer than  the original
one, the two paths get mixed up with undesirable results. The following patch
seems to solve the problem when applied to file zpath2.c [from the source for
ghostscript 2.5] :

31,34d30
< #include "gxfixed.h"
< #include "gxmatrix.h"
< #include "gzstate.h"
< 
86d81
< 	gx_path_share(igs->path);

	However, not being a ghostscript expert [it was the first time I even
looked at the  code],  I am probably  overlooking something (I'm not sure  if
this path ever gets freed for one thing). Would anyone care to confirm/infirm
this, and fix the patch if necessary?

-- 
/***************************************************************************\
|* Patrice Belleville 					 patrice@cs.sfu.ca *|
|*   --- Simon Fraser University is not responsible for my mistakes. ---   *|
\***************************************************************************/

Newsgroups: gnu.ghostscript.bug
From: shiva@krazykat.engin.umich.edu (Shawn D Way)
Subject: problem with Gs2.5 with tseng
Organization: University of Michigan Engineering, Ann Arbor
Distribution: gnu
Date: Mon, 14 Sep 1992 20:54:02 GMT

	I was trying to upgrade to Ghostscript 2.5 but when I did, I encountered this huge amount of problems:

1. Using the regular gs.exe, an image shows up on the screen , but only part of the paper that was written. This happen when I open other files also.

2. Using gs386.exe both set with -sDEVICE=tseng and without half of the screen goes black and the other half, the top stays white. In the white half, any file that I go to view makes color smears across the screen.

3. Using gswin.exe, the first file that I open goes fine. The second file that I try to open  either gives me a --restore-- error or a --repeat--- error.

	I'm using Qemm386 as a memory manager, Windows 3.1 and Superstor on a 486DX /33. Does any one know what's going on here???

Newsgroups: gnu.ghostscript.bug
From: alfie@dcs.warwick.ac.UK (Nick Holloway)
Subject: Problems with restore (and also dictionaries)
Organization: Department of Computer Science, Warwick University, England
Distribution: gnu
Date: Thu, 10 Sep 1992 17:26:11 GMT

I have just discovered a problem with Ghostscript 2.5.  It was triggered
by the code generated by psraster.  In this it reclaims VM by performing a
'restore save' in the procedure used to decode the image data.  The actual
code is of the following form:

    [...] {restore save GetImageRow} save 6 1 roll image
    [...]
    restore

This works fine on the printers, but causes Ghostscript to complain:

    Error: /invalidrestore in --restore--
    Operand stack:
	-savetype-

The following is a small fragment that will also demonstrate the error:

    save 10 { (Hello, World!\n) print restore save } repeat restore

Another (percieved) mis-feature of Ghostscript is the way it will
automatically expand dictionaries.  This recently lead to much head
scratching, since we could preview the file, but it would not print.
Is there a way of stopping the dictionaries being expanded?

--
Nick Holloway |  `O O'  | alfie@dcs.warwick.ac.uk, alfie@warwick.UUCP,
[aka `Alfie'] | // ^ \\ | ..!uunet!mcsun!uknet!warwick!alfie

Newsgroups: gnu.ghostscript.bug
From: ghost@aladdin.COM (L. Peter Deutsch)
Subject: Ghostscript 'invalidrestore' error
Reply-To: ghost@pa.dec.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 04:41:39 GMT

Re <9209110403.AA02109@cookie-crisp>
<1992Sep10.172611.25400@dcs.warwick.ac.uk>:

> I have just discovered a problem with Ghostscript 2.5.  It was triggered
> by the code generated by psraster.  In this it reclaims VM by performing a
> 'restore save' in the procedure used to decode the image data.  The actual
> code is of the following form:
> 
>     [...] {restore save GetImageRow} save 6 1 roll image
>     [...]
>     restore
> 
> This works fine on the printers, but causes Ghostscript to complain:
> 
>     Error: /invalidrestore in --restore--
>     Operand stack:
> 	-savetype-

I believe the problem arises because the 'image' operator allocates
some buffer storage in the same memory pool managed by save and
restore, so the restore (correctly, from its point of view) can't
deallocate it while the image operation is in progress.

This is not a trivial problem to fix; the fix will have to wait for
release 2.6 or later.  Meanwhile, perhaps you could contact the
author of psraster to see if they can find a less heavy-handed way of
doing the job (e.g., reuse a single buffer inside the loop, and wrap
a single save/restore around the whole thing).

> The following is a small fragment that will also demonstrate the error:
> ) pop restore
> 
>     save 10 { (Hello, World!\n) print restore save } repeat restore

This is obviously incorrect code.  The procedure in the { } is
allocated within the scope of the first 'save'.  The first 'restore'
is invalid, because it is attempting to deallocate a procedure that
is still being executed.  Do printers execute this without
complaining??

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: medin@cod.nosc.mil (Ted Medin)
Subject: What is ghostscript?
Organization: Naval Ocean Systems Center, San Diego
Distribution: gnu
Date: Tue, 8 Sep 1992 15:09:25 GMT

 Title says it all. Need a pointer to docs or ...
73, ted
n6trf

Newsgroups: gnu.ghostscript.bug
From: ghost@aladdin.COM (L. Peter Deutsch)
Subject: Re: Compile Errors in Ghostscript 2.5
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 04:28:56 GMT

Re <9209110327.AA01847@cookie-crisp>
<1992Sep10.024120.11467@sbcs.sunysb.edu>:

> In the compile for iinit.c, the following error messages occur:
> [...]
>         ./ccgs "cc  -O  -DSVR4" iinit.c
> "iinit.c", line 159: left operand must be modifiable lvalue: op "="
> "iinit.c", line 159: operand must be modifiable lvalue: op "++"
> "iinit.c", line 175: left operand must be modifiable lvalue: op "="
> "iinit.c", line 175: operand must be modifiable lvalue: op "++"
> "iinit.c", line 186: left operand must be modifiable lvalue: op "="
> "iinit.c", line 186: operand must be modifiable lvalue: op "++"
> "iinit.c", line 201: left operand must be modifiable lvalue: op "="
> mv: cannot access _temp_3084.o
> [...]
>         ./ccgs "cc  -O  -DSVR4" zprops.c
> "zprops.c", line 177: left operand must be modifiable lvalue: op "+="
> mv: cannot access _temp_3094.o
> [...]

It's a compiler bug.  The compiler is not interpreting 'const'
properly.  (Ghostscript compiles correctly with a wide variety of
ANSI-compliant compilers.)  Look for the comment about disabling
'const' in std.h, and remove the #ifndef around the #define.

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: reuver@mikro.ee.tu-berlin.de (Dirk Reuver)
Subject: page margin problems (especially lbp8 driver)
Organization: ZRZ/TU-Berlin
Distribution: gnu
Date: Mon, 7 Sep 1992 20:21:28 GMT

using ghostscript version 2.5 and a Canon LBP-4 laser printer, I
encountered severe problems due to incorrect positioning on
A4 paper. The doc says that the lbp8 driver uses A4 paper
by default, and from looking at the source code this seems
to be true, but everything is shifted one half inch to the
bottom of the page. With a LBP-4 this has the side effect that
the printer constantly ejects pages after it printed the
image. After some experiments, I found out that the additional
pages resulted from data beyond the page length. With
modifications in the driver code, I was able to adjust size
and position to a reference printed on a NEC LC-890 Postscript
printer. But what really surprised me was that using a different
program (postscript output too), the positioning was nuts again.
How can that be? I understood that Postscript defines positions 
from an origin at the lower left corner of the paper. Raster output
of course begins at the top left corner of the page, and it
excludes the margins. This means that I have to give any
interpreter the correct paper size and margins, which is
device dependant of course. BUT, once defined (with the driver code)
this should work with ALL postscript code. Well, it doesn't,
and I don't get it.

To get correct printout for my first PS code, I had to skip
some of the raster data. To my surprise, I found out that
the raster data represented a larger area than fits on the
page (even if I take the margins into account). I tried
using the papersize switch on the command line, but nothing
changed.

Any ideas ?

Dirk

__________________________________________________________________________
Dirk Reuver    DD6RE                  Phone:  +49 30 314 26705
Institute for Microelectronics        FAX:    +49 30 314 24597
Technical University Berlin           Email:  reuver@mikro.ee.tu-berlin.de
                    "You say tomato, I say tomato"

Newsgroups: gnu.ghostscript.bug
From: iigsa01@convex.zdv.uni-tuebingen.de (Andreas Schilling)
Subject: Re: output of dvips too large in gs2.5
Reply-To: andreas@gris.informatik.uni-tuebingen.de
Organization: Universitaet Tuebingen, WSI/GRIS, FRG
Distribution: gnu
Date: Thu, 10 Sep 1992 08:20:54 GMT

I wrote:

>GS25 (MSDOS) works fine here, but I am not any more able to preview my TeX
>documents. The PS files produced with dvips are scaled with a factor of
>about 1.5 and thus don't fit on the screen any more. All the other PS files 
>are displayed in the correct size.

An additional hint:

If I replace all occurences of a4 (my paper size, works exactly the same with
letter) with a1234 in my PS file, then the scaling is fine. Maybe dvips uses
a4 in a different way than GS, or maybe setting the paper size in GS uses the
horizontal size of the screen and the document to fit the size???

At least the TeX output can be previewed again with GS.

Andreas Schilling
--
|            Andreas  Schilling            |     Universitaet Tuebingen     |
| andreas@gris.informatik.uni-tuebingen.de |   Wilhelm-Schickard-Institut   |
|          tel.: +49 7071 29 5463          |   Auf der Morgenstelle 10/C9   |
|          fax.: +49 7071 29 5400          | D-7400 Tuebingen, West Germany |

Newsgroups: gnu.ghostscript.bug
From: patrice@cs.sfu.ca (Patrice Belleville)
Subject: Scanner bug?
Summary: gs confused after (file) run
Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada
Distribution: gnu
Date: Mon, 14 Sep 1992 20:34:02 GMT

	There is a problem with the `run' command in version 2.5 (and 2.5.1).
It seems that the interpreter gets confused when executing  long files.  More
precisely,  once  the file  has  been read and  executed,  interpretation may
resume at an arbitrary point of the included file (possibly in  the middle of
a comment) instead of continuing from just after the `run'. This  bug was not
present in version 2.4.1 (I don't know where to look exactly for the problem,
and so I cannot suggest any fix).

-- 
/***************************************************************************\
|* Patrice Belleville 					 patrice@cs.sfu.ca *|
|*   --- Simon Fraser University is not responsible for my mistakes. ---   *|
\***************************************************************************/

Newsgroups: gnu.ghostscript.bug
From: ian@centric.com (Ian Macky)
Subject: Unexpected interpreter error -9 in GS 2.5
Organization: Centric Engineering Systems
Distribution: gnu
Date: Wed, 9 Sep 1992 01:33:56 GMT

I just built GS 2.5 (as retrieved from gatekeeper.dec.com) on my SPARC 2
running SunOS 4.1.2.  Had problems using acc, but compiled fine with gcc.

Runs great in the build directory, but if I invoke the gs executable from
anywhere else (up one, down one, copy it to /tmp, anything) then it bombs
with the following:

Initializing...
Unexpected interpreter error -9!
Error object: (640)op(0x5c:file)0x10d20
Operand stack at 0x62fc0:
..2fc0: 0x0a name ---------- 0x0254 0x000f2c00 = .ttyin
..2fc8: 0x0f str  ---wrx---- 0x0008 0x000f679f = /dev/tty
..2fd0: 0x0f str  ---wrx---- 0x0001 0x000f679e = R
Execution stack at 0x62ac0:
..2ac0: 0x0c oper ------e--- 0x0029 0x00007a6c = %interp_exit
..2ac8: 0x04 file ----rxe--- 0x0001 0x000f31f8

Any ideas?  I've been using the golfer.ps file to test.  That is, when
connected to where I built it,

	./gs golfer.ps

works, but from there

	mkdir a; cd a; ../gs ../golfer.ps

dies as above.

--ian

Newsgroups: gnu.ghostscript.bug
From: CHEM193@cantva.canterbury.ac.nz
Subject: Ghsotscript
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 11:15:44 GMT

To whom it may concern,

We are having problems using Ghostscript 2.5 on the PC and on an RS/6000 to
convert a postscript file into a pbm file, using the included pstopbm filter.

We are using the format gs pnm8run [filename], where 8 is the number of bits
per pixel we want, but it just doesn't work.
If you have any ideas, they would be greatly asppreciated, as we have some
graphing packages that only export in postscript format, and we would like
to modify them in some way.

Thanks in advance.
Mark Baker, c/- Chem193@csc.canterbury.ac.nz

P.S. Do you e-mail copies of ghostscript?  If so, then we would really
     appreciate a copy of 2.5.1, because we don't have any ftp sites with
     it.