Is this a change in behaviour? And if so, against what version(s)?

gs-9.15 search the strings "Resource" in the path to locate the Resource directory.
However, it is prefix search.
When there is a similar strings before true Resource directory,
it fails recognize the Resource directory.

My patch changes the search strings "Resoruce" to "Resource/".

"Resources" matches "Resource".
"Resources" doesn't match "Resource/".
By this, the
"/path/to/Resources/share/ghostscript/9.15/Resource"
directory problem is solved.

However, the following cases
"/path/to/foo-Resource/share/ghostscript/9.15/Resource"
"/path/to/Resource/share/ghostscript/9.15/Resource"
can't be solved.

(In reply to Masamichi Hosoda from comment #2)
> gs-9.15 search the strings "Resource" in the path to locate the Resource
> directory.
> However, it is prefix search.
> When there is a similar strings before true Resource directory,
> it fails recognize the Resource directory.
> 
> My patch changes the search strings "Resoruce" to "Resource/".
> 
> "Resources" matches "Resource".
> "Resources" doesn't match "Resource/".
> By this, the
> "/path/to/Resources/share/ghostscript/9.15/Resource"
> directory problem is solved.
> 
> However, the following cases
> "/path/to/foo-Resource/share/ghostscript/9.15/Resource"
> "/path/to/Resource/share/ghostscript/9.15/Resource"
> can't be solved.

That was not what I asked, exactly. Did previous versions of Ghostscript work the way you want, or has the behaviour always been that way and you are looking to change it?

gs-8.70 didn't have this problem.
I've found it when I tried to upgrade ghostscript from 8.70 to 9.15.

(In reply to Masamichi Hosoda from comment #4)
> gs-8.70 didn't have this problem.
> I've found it when I tried to upgrade ghostscript from 8.70 to 9.15.

I see. Well, 8.70 did not use ICC profiles, so the problem could not arise. I misread your meaning, and thought you meant Ghostscript couldn't find it's Postscript resources (Init, Font, CMap etc) as well as the iccprofiles.

I'll have to look into this properly, when I get time, as I suspect there might be a better approach than the original code is using.

Oh, and in the meantime, you can work around the problem by setting the path explicitly on the command line: -sICCProfilesDir=

In the case of pure gs-9.15 (without my patch) with -sICCProfilesDir option,
ICC profiles error doesn't arise.

But, gs shows the following warning and doesn't seem able to find fonts etc.

```
*** Warning: GenericResourceDir doesn't point to a valid resource directory.
               the -sGenericResourceDir=... option can be used to set this.
```

Created attachment 14905 [details]
Log of CUPS where the ghostscript error happens

Hi,

I am experiencing the bug with 9.22 release. The workaround does not apply for me because it happens during a CUPS printing process, so I cannot change what CUPS sends to the ghostscripts tools. It happens during printing a test page.

I attach the log, see lines 3455 in particular (job 71 is the one with bug).However I don't remembre having this bug on 9.20 and previous, the bug seems to be appeared recently (Debian Buster). Any help would be appreciated, but I can test or give further info if needed.

Regards

(In reply to Jean-Philippe MENGUAL from comment #9)
> Hi,
> 
> I am experiencing the bug with 9.22 release.

No, you are experiencing a completely different problem. Please don't guess at problems, or append 'me too' to existing bugs.

While the error message does mention ICC profiles,it doe snot mention the GenericResourceDirectory:

D [18/Mar/2018:03:56:11 +0100] [Job 71] ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find default_gray.icc 
D [18/Mar/2018:03:56:11 +0100] [Job 71] | ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find device profile
D [18/Mar/2018:03:56:11 +0100] [Job 71] Unrecoverable error: rangecheck in .putdeviceprops


The actual error is the rangecheck, which is quite different.

> The workaround does not apply
> for me because it happens during a CUPS printing process, so I cannot change
> what CUPS sends to the ghostscripts tools.

I'm reasonably certain you *can* change what CUPS sends, though I'm not a CUPS expert. In this case I think you would need to remove the setpagedevice from the command line.

D [18/Mar/2018:03:56:10 +0100] [Job 71] Ghostscript command line: gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -r600x600 -dMediaPosition=1 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=1 -dcupsColorOrder=0 -dcupsColorSpace=3 -dcupsCompression=17 -scupsPageSizeName=A4 -I/usr/share/cups/fonts -c \'<</.HWMargins[10.750000 15.000000 10.750000 15.000000] /Margins[0 0]>>setpagedevice\' -f -_

The only way to tell for sure would be to try removing each option until the problem goes away. You can do *that* from the command shell yourself.


> I attach the log, see lines 3455 in particular (job 71 is the one with
> bug).However I don't remembre having this bug on 9.20 and previous, the bug
> seems to be appeared recently (Debian Buster). Any help would be
> appreciated, but I can test or give further info if needed.

If you can't alter the CUPS command line then clearly nothing is going to help you except downgrading to an earlier version, or upgrading to the next release.

Hi,

Well now it is more clear for me after some help on a support mailing list. I could isolate the fact that CUPS does not interfer, isolate the command and now we can play with it. As I don't find any option which seem to be problematic, I propose to start from zero. So:

gs -sOutputFile=out.ras input.pdf 

I even tried without option at all:

gs input.pdf

The resulting message is exactly the same:
GPL Ghostscript 9.22 (2017-10-04)
Copyright (C) 2017 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
  ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find default_gray.icc
| ./base/gsicc_manage.c:2035: gsicc_init_iccmanager(): cannot find default icc profile
  ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find default_gray.icc
| ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find device profile
**** Unable to open the initial device, quitting.

So as I have no knowledge at all about gs stuff and such topic (basically I juste want to print a doc), I cannot say wether it is a bug, similar or not as this, or wther I have some missing thing on the system, but the messages are the same as the initial report and I really dont know what to do and if it is a bug, I would like to help fixing it (all the more as with it, I can no longer print anything).

Thanks for your feedback, any suggestion is welcome.

Regards

(In reply to Jean-Philippe MENGUAL from comment #11)

> I even tried without option at all:
> 
> gs input.pdf
> 
> The resulting message is exactly the same:
> GPL Ghostscript 9.22 (2017-10-04)
> Copyright (C) 2017 Artifex Software, Inc.  All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
>   ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
> default_gray.icc
> | ./base/gsicc_manage.c:2035: gsicc_init_iccmanager(): cannot find default
> icc profile
>   ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
> default_gray.icc
> | ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find device
> profile
> **** Unable to open the initial device, quitting.

OK so firstly you haven't supplied us with an example file to use (ie the file you are using) which means we can't reproduce your problem.

Secondly, you haven't told us where you got the Ghostscript binary that you are using. This is important because the various Linux distributions alter the code which we ship, and build Ghostscript in ways other then the default.

Finally, not supplying any parameters at all isn't a great way to test Ghostscript. What happens then is that you get the default device, or the fist device alphabetically in the list of devices (I think).

Since we aren't using the same build as you are, we don't know whether (for example) you have X support, which will determine whether the default device is the X display device, or what the default device is.

The best way to run a tets will be to use soemthign specific. For example, something like:

./gs -sDEVICE=tiff24nc -sOutputFile=out.tif input.pdf


> 
> So as I have no knowledge at all about gs stuff and such topic (basically I
> juste want to print a doc), I cannot say wether it is a bug, similar or not
> as this, or wther I have some missing thing on the system, but the messages
> are the same as the initial report

No they absolutely are not the same. For example the initial report says:

*** Warning: GenericResourceDir doesn't point to a valid resource directory.
               the -sGenericResourceDir=... option can be used to set this.

Which is not present anywhere in the output you have sent.


> and I really dont know what to do and if
> it is a bug, I would like to help fixing it (all the more as with it, I can
> no longer print anything).
> 
> Thanks for your feedback, any suggestion is welcome.

Get the Ghostscript source code for version 9.23 (available from the Ghostscript downloads site), build the source, try the resulting executable with the command line I stated above.

If that doesn't work then please open a *different* bug report. Your problem is absolutely not the same as the original report.

If it does work, then you can work forward from that point, knowing that you at least have a functional Ghostscript binary.

Hi,

(In reply to Ken Sharp from comment #12)
> (In reply to Jean-Philippe MENGUAL from comment #11)
> 
> > I even tried without option at all:
> > 
> > gs input.pdf
> > 
> > The resulting message is exactly the same:
> > GPL Ghostscript 9.22 (2017-10-04)
> > Copyright (C) 2017 Artifex Software, Inc.  All rights reserved.
> > This software comes with NO WARRANTY: see the file PUBLIC for details.
> >   ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
> > default_gray.icc
> > | ./base/gsicc_manage.c:2035: gsicc_init_iccmanager(): cannot find default
> > icc profile
> >   ./base/gsicc_manage.c:1148: gsicc_open_search(): Could not find
> > default_gray.icc
> > | ./base/gsicc_manage.c:1799: gsicc_set_device_profile(): cannot find device
> > profile
> > **** Unable to open the initial device, quitting.
> 
> OK so firstly you haven't supplied us with an example file to use (ie the
> file you are using) which means we can't reproduce your problem.

ok. You can find it at:
http://demo.accelibreinfo.eu/input.pdf

Note I tried with other PDF files with a similar result. See as an example http://demo.accelibreinfo.eu/CARTE_VISITE_Corentin_4.pdf

> Secondly, you haven't told us where you got the Ghostscript binary that you
> are using. This is important because the various Linux distributions alter
> the code which we ship, and build Ghostscript in ways other then the default.

I understand. In my first post I said I use Debian Buster (testing), future 10.0. They use ghoscript 9.22, they mention 9.22~dfsg-2.
 
> Finally, not supplying any parameters at all isn't a great way to test
> Ghostscript. What happens then is that you get the default device, or the
> fist device alphabetically in the list of devices (I think).

ah. Sorry but I have really no skills in gs. Initially I used cups device. Where are listed devices so that I can test each of them if useful?

> Since we aren't using the same build as you are, we don't know whether (for
> example) you have X support, which will determine whether the default device
> is the X display device, or what the default device is.

I ran under mate-terminal. I have tried now on tty. Same result.

> The best way to run a tets will be to use soemthign specific. For example,
> something like:
> 
> ./gs -sDEVICE=tiff24nc -sOutputFile=out.tif input.pdf

I tried this command. The error is nearly the same, but now more than the initial default_grau.icc not found, gs says that it cannot find default_rgb.icc.

I can confirm that both files are present on my system.

> 
> > 
> > So as I have no knowledge at all about gs stuff and such topic (basically I
> > juste want to print a doc), I cannot say wether it is a bug, similar or not
> > as this, or wther I have some missing thing on the system, but the messages
> > are the same as the initial report
> 
> No they absolutely are not the same. For example the initial report says:
> 
> *** Warning: GenericResourceDir doesn't point to a valid resource directory.
>                the -sGenericResourceDir=... option can be used to set this.
> 
> Which is not present anywhere in the output you have sent.
> 
> > and I really dont know what to do and if
> > it is a bug, I would like to help fixing it (all the more as with it, I can
> > no longer print anything).
> > 
> > Thanks for your feedback, any suggestion is welcome.
> 
> Get the Ghostscript source code for version 9.23 (available from the
> Ghostscript downloads site), build the source, try the resulting executable
> with the command line I stated above.
> 
> If that doesn't work then please open a *different* bug report. Your problem
> is absolutely not the same as the original report.
> 
> If it does work, then you can work forward from that point, knowing that you
> at least have a functional Ghostscript binary.

ok many thanks for these suggestions. I will try this.

(In reply to Jean-Philippe MENGUAL from comment #13)

> ok. You can find it at:
> http://demo.accelibreinfo.eu/input.pdf

Please attach files to bug reports. In fact, please open a *new* bug report (as I already asked twice), rather than continuing to clutter up this different report.


> > Secondly, you haven't told us where you got the Ghostscript binary that you
> > are using. This is important because the various Linux distributions alter
> > the code which we ship, and build Ghostscript in ways other then the default.
> 
> I understand. In my first post I said I use Debian Buster (testing), future
> 10.0. They use ghoscript 9.22, they mention 9.22~dfsg-2.

So, its not built using our sources and our default build configuration. Which means we can't really say much about it. Perhaps the packager broke it.


> ah. Sorry but I have really no skills in gs. Initially I used cups device.
> Where are listed devices so that I can test each of them if useful?

gs --help

Note that this will give you considerable useful information; a basic usage description, the default device, the list of available devices and the current search path for Ghostscript.

Or read the documentation:

https://www.ghostscript.com/doc/9.23/Devices.htm

But since this isn't a default build of Ghostscript, rely on what the binary tells you is built-in when you run with --help.


> 
> > Since we aren't using the same build as you are, we don't know whether (for
> > example) you have X support, which will determine whether the default device
> > is the X display device, or what the default device is.
> 
> I ran under mate-terminal. I have tried now on tty. Same result.

Again, you aren't supplying a device (unless you've tried a different command line). The terminal you are using isn't really relevant.


> I tried this command. The error is nearly the same, but now more than the
> initial default_grau.icc not found, gs says that it cannot find
> default_rgb.icc.
> 
> I can confirm that both files are present on my system.

To be honest, the best way to report problems is to capture the output by redirecting stdout and stderr to a file, and attach the file to the bug report (again, please don't do this here, open a new report as it is a different problem).

I can say that the Ghostscript 9.22 release, built from the sources we supply and using the default build configuration doesn't have this problem.

You could also try:

downloading the built binary from *our* downloads page and running it on your system. If you are lucky it will run (it may well not) and is at least built in a way we can reproduce.

Complain to the packager of Ghostscript for your system. Then they can contact us and we can discuss it with them. They will be able to tell us what patches they have applied, and what configuration options they have used to build Ghostscript.

And finally as I already mentioned you can get the source code and build it yourself.

I believe the original reported problem is resolved with:

https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2de092758980

If other (even related) problems still exist, please open a new bug, rather than add to the confusion of this one.