I *suspect* this may be fixed by this commit:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=568854


Can't be sure, though.

(In reply to comment #1)
> I *suspect* this may be fixed by this commit:
> 
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=568854
> 
> 
> Can't be sure, though.

Fixed up gs_lev2.ps , now I am just getting Unrecoverable error: typecheck in .putdeviceprops

The pdf is good and like I said it does work on 8.64,72 etc ...

Well, in that case, you'll really have to provide us with a sample file to test.

Created attachment 8230 [details]
Sample File

Must of eaten it the first time

Well, it *seems* to work fine with the current master in our git repository, and with the (patched) 9.04 release in the Ubuntu Oneiric 11.10 release, so it's probably a issue that's been fixed since 9.04 was released.

(In reply to comment #5)
> Well, it *seems* to work fine with the current master in our git repository,
> and with the (patched) 9.04 release in the Ubuntu Oneiric 11.10 release, so
> it's probably a issue that's been fixed since 9.04 was released.

OK. I downloaded the Fedora 16 rpm and it is not fixed in there. Should I take this up with Fedora ? Or is there a patch I can apply...

Well, I think that patch I indicated above was the only fix in this area that was in the Postscript resources, so anything else will mean patching the Ghostcript source, and rebuilding the binary.

Given that, you'll probably need to go through the package maintainer anyway.


Also, I can't find a list of patches Ubuntu has adopted since our 9.04 release.

(In reply to comment #7)
> Well, I think that patch I indicated above was the only fix in this area that
> was in the Postscript resources, so anything else will mean patching the
> Ghostcript source, and rebuilding the binary.
> 
> Given that, you'll probably need to go through the package maintainer anyway.
> 
> 
> Also, I can't find a list of patches Ubuntu has adopted since our 9.04 release.

Opened a ticket at Fedora 


https://bugzilla.redhat.com/show_bug.cgi?id=769436

(In reply to comment #8)
> (In reply to comment #7)
> > Well, I think that patch I indicated above was the only fix in this area that
> > was in the Postscript resources, so anything else will mean patching the
> > Ghostcript source, and rebuilding the binary.
> > 
> > Given that, you'll probably need to go through the package maintainer anyway.
> > 
> > 
> > Also, I can't find a list of patches Ubuntu has adopted since our 9.04 release.
> 
> Opened a ticket at Fedora 
> 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=769436


Did you try this on 64 bit or 32 bit? I found this that seems to describe the same problem ...

http://www.ghostscript.com/pipermail/gs-devel/2010-July/008785.html

(In reply to comment #8)
> (In reply to comment #7)
> > Well, I think that patch I indicated above was the only fix in this area that
> > was in the Postscript resources, so anything else will mean patching the
> > Ghostcript source, and rebuilding the binary.
> > 
> > Given that, you'll probably need to go through the package maintainer anyway.
> > 
> > 
> > Also, I can't find a list of patches Ubuntu has adopted since our 9.04 release.
> 
> Opened a ticket at Fedora 
> 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=769436


Did you try this on 64 bit or 32 bit? I found this that seems to describe the same problem ...

http://www.ghostscript.com/pipermail/gs-devel/2010-July/008785.html
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Well, I think that patch I indicated above was the only fix in this area that
> > > was in the Postscript resources, so anything else will mean patching the
> > > Ghostcript source, and rebuilding the binary.
> > > 
> > > Given that, you'll probably need to go through the package maintainer anyway.
> > > 
> > > 
> > > Also, I can't find a list of patches Ubuntu has adopted since our 9.04 release.
> > 
> > Opened a ticket at Fedora 
> > 
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=769436
> 
> 
> Did you try this on 64 bit or 32 bit? I found this that seems to describe the
> same problem ...
> 
> http://www.ghostscript.com/pipermail/gs-devel/2010-July/008785.html

Sorry, I forgot to add I downloaded the source from the git repo and build it on Fedora 15 64 bit and got the same error.

(In reply to comment #8)
> (In reply to comment #7)
> > Well, I think that patch I indicated above was the only fix in this area that
> > was in the Postscript resources, so anything else will mean patching the
> > Ghostcript source, and rebuilding the binary.
> > 
> > Given that, you'll probably need to go through the package maintainer anyway.
> > 
> > 
> > Also, I can't find a list of patches Ubuntu has adopted since our 9.04 release.
> 
> Opened a ticket at Fedora 
> 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=769436


Did you try this on 64 bit or 32 bit? I found this that seems to describe the same problem ...

http://www.ghostscript.com/pipermail/gs-devel/2010-July/008785.html
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Well, I think that patch I indicated above was the only fix in this area that
> > > was in the Postscript resources, so anything else will mean patching the
> > > Ghostcript source, and rebuilding the binary.
> > > 
> > > Given that, you'll probably need to go through the package maintainer anyway.
> > > 
> > > 
> > > Also, I can't find a list of patches Ubuntu has adopted since our 9.04 release.
> > 
> > Opened a ticket at Fedora 
> > 
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=769436
> 
> 
> Did you try this on 64 bit or 32 bit? I found this that seems to describe the
> same problem ...
> 
> http://www.ghostscript.com/pipermail/gs-devel/2010-July/008785.html

Sorry, I forgot to add I downloaded the source from the git repo and build it on Fedora 15 64 bit and got the same error.
(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Well, I think that patch I indicated above was the only fix in this area that
> > > was in the Postscript resources, so anything else will mean patching the
> > > Ghostcript source, and rebuilding the binary.
> > > 
> > > Given that, you'll probably need to go through the package maintainer anyway.
> > > 
> > > 
> > > Also, I can't find a list of patches Ubuntu has adopted since our 9.04 release.
> > 
> > Opened a ticket at Fedora 
> > 
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=769436
> 
> 
> Did you try this on 64 bit or 32 bit? I found this that seems to describe the
> same problem ...
> 
> http://www.ghostscript.com/pipermail/gs-devel/2010-July/008785.html
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > Well, I think that patch I indicated above was the only fix in this area that
> > > > was in the Postscript resources, so anything else will mean patching the
> > > > Ghostcript source, and rebuilding the binary.
> > > > 
> > > > Given that, you'll probably need to go through the package maintainer anyway.
> > > > 
> > > > 
> > > > Also, I can't find a list of patches Ubuntu has adopted since our 9.04 release.
> > > 
> > > Opened a ticket at Fedora 
> > > 
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=769436
> > 
> > 
> > Did you try this on 64 bit or 32 bit? I found this that seems to describe the
> > same problem ...
> > 
> > http://www.ghostscript.com/pipermail/gs-devel/2010-July/008785.html
> 
> Sorry, I forgot to add I downloaded the source from the git repo and build it
> on Fedora 15 64 bit and got the same error.

I downloaded the source out of git and built on Fedora 15 and get the same error.

Did you try this on 64 bit or 32 bit? I found this that seems to describe the
same problem ...

http://www.ghostscript.com/pipermail/gs-devel/2010-July/008785.html

I did, but with limited support for the display device, I only got it to run the file without the ICC profile error, I didn't try any further.

Now I have, and it seems there's a little "hiccup". I haven't a clue how this worked on 8.x, but......

It seems that, because one of the things DisplayHandle can be is a pointer value, and on 64 bit builds, that can (obviously!) be longer than 32 bits. But Postscript only allows 32 bit number values, and these settings work through the Postscript machinery, it needs to be compatible with that limitation.

So, on 64 bit systems the parameter for DisplayHandle is expected to be a string, rather than an integer or a long. So, if you convert your DisplayHandle parameter to a string, and use

-sDisplayHandle="handle value string"


That *might* help.

(In reply to comment #12)
> I did, but with limited support for the display device, I only got it to run
> the file without the ICC profile error, I didn't try any further.
> 
> Now I have, and it seems there's a little "hiccup". I haven't a clue how this
> worked on 8.x, but......
> 
> It seems that, because one of the things DisplayHandle can be is a pointer
> value, and on 64 bit builds, that can (obviously!) be longer than 32 bits. But
> Postscript only allows 32 bit number values, and these settings work through
> the Postscript machinery, it needs to be compatible with that limitation.
> 
> So, on 64 bit systems the parameter for DisplayHandle is expected to be a
> string, rather than an integer or a long. So, if you convert your DisplayHandle
> parameter to a string, and use
> 
> -sDisplayHandle="handle value string"
> 
> 
> That *might* help.

Did not work, tried -dDisplayHandle="0". The reason I brought this back up is that I installed 64 bit 8.71 and it failed with the same error. All my running installs are 32 bit, this is the first crack at 64 bit....

(In reply to comment #13)
> (In reply to comment #12)
> > I did, but with limited support for the display device, I only got it to run
> > the file without the ICC profile error, I didn't try any further.
> > 
> > Now I have, and it seems there's a little "hiccup". I haven't a clue how this
> > worked on 8.x, but......
> > 
> > It seems that, because one of the things DisplayHandle can be is a pointer
> > value, and on 64 bit builds, that can (obviously!) be longer than 32 bits. But
> > Postscript only allows 32 bit number values, and these settings work through
> > the Postscript machinery, it needs to be compatible with that limitation.
> > 
> > So, on 64 bit systems the parameter for DisplayHandle is expected to be a
> > string, rather than an integer or a long. So, if you convert your DisplayHandle
> > parameter to a string, and use
> > 
> > -sDisplayHandle="handle value string"
> > 
> > 
> > That *might* help.
> 
> Did not work, tried -dDisplayHandle="0". The reason I brought this back up is
> that I installed 64 bit 8.71 and it failed with the same error. All my running
> installs are 32 bit, this is the first crack at 64 bit....

-sDisplayHandle="handle value string"
^^


Not -d.....

(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > I did, but with limited support for the display device, I only got it to run
> > > the file without the ICC profile error, I didn't try any further.
> > > 
> > > Now I have, and it seems there's a little "hiccup". I haven't a clue how this
> > > worked on 8.x, but......
> > > 
> > > It seems that, because one of the things DisplayHandle can be is a pointer
> > > value, and on 64 bit builds, that can (obviously!) be longer than 32 bits. But
> > > Postscript only allows 32 bit number values, and these settings work through
> > > the Postscript machinery, it needs to be compatible with that limitation.
> > > 
> > > So, on 64 bit systems the parameter for DisplayHandle is expected to be a
> > > string, rather than an integer or a long. So, if you convert your DisplayHandle
> > > parameter to a string, and use
> > > 
> > > -sDisplayHandle="handle value string"
> > > 
> > > 
> > > That *might* help.
> > 
> > Did not work, tried -dDisplayHandle="0". The reason I brought this back up is
> > that I installed 64 bit 8.71 and it failed with the same error. All my running
> > installs are 32 bit, this is the first crack at 64 bit....
> 
> -sDisplayHandle="handle value string"
> ^^
> 
> 
> Not -d.....

Good news and bad news...

From the command line no errors.
When I try to call it from the GS API (so in my case) I get

Unrecoverable error: rangecheck in .putdeviceprops

This is the case in my working 32 bit version and the 64 bit ...

(In reply to comment #15)
> 
> Good news and bad news...
> 
> From the command line no errors.
> When I try to call it from the GS API (so in my case) I get
> 
> Unrecoverable error: rangecheck in .putdeviceprops
> 
> This is the case in my working 32 bit version and the 64 bit ...

Well, you have a couple of options. Since you seem reasonably confident with such things, you could build yourself a debug build of the Ghostscript .so lib, and put a break point in display_put_params() and step through to find where/why it throws an error (assuming it is the display device put_params that throws the erro, and not the generic code).

OR, if you could throw together a simple test harness which reproduces how you are driving Ghostscript in your app, I, or one of us, can look into what's causing the error.

Clealy, *our* implementations work a bit differently, so aren't driving this stuff in the same way as yours.

(In reply to comment #16)
> (In reply to comment #15)
> > 
> > Good news and bad news...
> > 
> > From the command line no errors.
> > When I try to call it from the GS API (so in my case) I get
> > 
> > Unrecoverable error: rangecheck in .putdeviceprops
> > 
> > This is the case in my working 32 bit version and the 64 bit ...
> 
> Well, you have a couple of options. Since you seem reasonably confident with
> such things, you could build yourself a debug build of the Ghostscript .so lib,
> and put a break point in display_put_params() and step through to find
> where/why it throws an error (assuming it is the display device put_params that
> throws the erro, and not the generic code).
> 
> OR, if you could throw together a simple test harness which reproduces how you
> are driving Ghostscript in your app, I, or one of us, can look into what's
> causing the error.
> 
> Clealy, *our* implementations work a bit differently, so aren't driving this
> stuff in the same way as yours.

I finally figured out what the difference between -s and -d mean and it works fine. 

May I suggest that the documentation here 
http://ghostscript.com/doc/current/API.htm#display

be updated from 

The callbacks are for device open, close, resize, sync, page, memory allocation and updating. Each callback function contains a handle can be set using

    -dDisplayHandle=1234 

to 

 -sDisplayHandle=1234 

and 

this code fragment

sprintf(arg2, "-dDisplayHandle=%d", 0);

be changed to 

sprintf(arg2, "-sDisplayHandle=%d", 0);


From the source code this seems to be the preferred way and for me it works on both 32 bit and 64 bit ghostscript, from versions 8.64 upwards ...

Great, thanks for confirming.

I'll look at updating the documentation before the next release (note: the correct information is actually in gdevdsp.h - I'd always suggest checking relevant header files, since documentation does tend to rot over time).

*** This bug has been marked as a duplicate of bug 692532 ***