Hi all,

While looking to fix a bug in Ghostscript, I stumbled upon a problem
that concerns running it on OpenVMS. I=92m not an OpemVMS user (I=92m
rather OpemVMS-ignorant), and I wouldn=92t want break something.

In short:
What=92s the filename template to use for enumerating file-based
PostScript Resources of a given Category?

Details:

A comment in gs_res.ps line 530 says "% Resource files on OpenVMS
require a separate template (gs:[dir.*]*)". Somehow I suspect it wants
to pass

    "dev:[generic.resource.dir" + "category.*]originaltemplate"

to .generate_dir_list_templates_with_length, which does not look right
(one directory level too deep?).

Or maybe it intends to pass

    "dev:[generic.resource.dir" + "category]originaltemplate.*"

which (I think) has its own problems (the ".*" could mean "all
extensions" or "all versions", depending on originaltemplate?).

However what it does is pass

    "dev:[generic.resource.dir" + "category]originaltemplate]*" (note
the use of "]")

To me, this looks incorrect. And even unnecessary, shouldn=92t the
preceding call, with

    "dev:[generic.resource.dir" + "category]originaltemplate"

be enough? And if a 2nd template is necessary for searching into
GenericResourceDir, why isn=92t it necessary for searching into LIBPATH
too?

TIA for any clarification,
sags

On 6/28/12 12:17 PM, SaGS wrote:
> Hi all,
>
> While looking to fix a bug in Ghostscript, I stumbled upon a problem
> that concerns running it on OpenVMS. I�m not an OpemVMS user (I�m
> rather OpemVMS-ignorant), and I wouldn�t want break something.
>
> In short:
> What�s the filename template to use for enumerating file-based
> PostScript Resources of a given Category?
>
> Details:
>
> A comment in gs_res.ps line 530 says "% Resource files on OpenVMS
> require a separate template (gs:[dir.*]*)". Somehow I suspect it wants
> to pass
>
>      "dev:[generic.resource.dir" + "category.*]originaltemplate"
>
> to .generate_dir_list_templates_with_length, which does not look right
> (one directory level too deep?).
>
> Or maybe it intends to pass
>
>      "dev:[generic.resource.dir" + "category]originaltemplate.*"
>
> which (I think) has its own problems (the ".*" could mean "all
> extensions" or "all versions", depending on originaltemplate?).
>
> However what it does is pass
>
>      "dev:[generic.resource.dir" + "category]originaltemplate]*" (note
> the use of "]")
>
> To me, this looks incorrect. And even unnecessary, shouldn�t the
> preceding call, with
>
>      "dev:[generic.resource.dir" + "category]originaltemplate"
>
> be enough? And if a 2nd template is necessary for searching into
> GenericResourceDir, why isn�t it necessary for searching into LIBPATH
> too?

The VMS filename parsing inside Ghostscript is broken.  If I remember 
correctly, is doesn't properly differentiate between what goes between 
directory names (a .) and what goes at the end of a directory name (a 
]).  This is also very prevalent in the various Ghostscript make files.

(A filepath with a single directory reads as follows: dev:[dir]file.ext
  A filepath with multiple directories reads as follows:
  dev:[dir1.dir2.dir3]file.ext).

For example, ghostscript on VMS might have a value of gs_lib:[resource] 
for GenericResourceDir.  In trying to find GS_INIT.PS, it must add the 
subdirectory [.init] and the filename gs_init.ps.  To do this, the 
process it needs to take is as follows:

If GenericResourceDir ends in a ] then:
   1. remove the trailing ]
   2. append file_name_directory_separator (a "." for VMS)
   3. append the directory name (init, in this case).
   4. append file_name_separator (a "]" for VMS)
   5. append file name (gs_init.ps)

If GenericResourceDir ends in a : then:
   1. append [ (there doesn't seem to be a variable defined for this)
   2. append the directory name
   3. append file_name_separator (because this is the end of the
      directory part of the specification)
   4. append file name

If I remember the code correctly, it is always using 
file_name_separator, even when concatenating two directory names 
together, and never uses file_name_directory_separator.  If I'm 
remembering correctly, that is where the logic needs to be fixed.

Mark Berryman

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 2012-06-28 22:14:58 +0000, Mark Berryman said:
> The VMS filename parsing inside Ghostscript is broken.  If I remember 
> correctly, is doesn't properly differentiate between what goes between 
> directory names (a .) and what goes at the end of a directory name (a 
> ]).  This is also very prevalent in the various Ghostscript make files.

The C RTL deals with Unix slash-format filenames mostly-fine.  Might 
want to try not using the native VMS syntax, there?

-- 
--
Pure Personal Opinion | HoffmanLabs LLC

Hi and thanks for the response.

I took a look at the source code in your ghostscript-9_05.zip, and I
think you are hit by 2 problems, both completely different from mine.

The 1st is that makefiles have a single macro $(D) that is used both
as .file_name_separator ("]" on OpenVMS)
and .file_name_directory_separator ("." on OpenVMS). The fix would be
to define 2 macros. It's not conceptually a complicated fix, but looks
extensive.

The 2nd is that the %rom% file system is built (psromfs.mak) with "/"
hardcoded for both 2 separators; not sure how the actual device works.
The big problem with this is the %rom% and %os% (host files) devices
use different conventions, so functions that concatenate/ split/ etc
filenames, and which obey the host syntax, fail with the %rom%. I
think the correct fix is to change the %rom% to always use the same
conventions as the host; for example you will see "%rom%
[Resource.CMap]Adobe-GB1-0" inthere, and not "%rom%Resource/CMap/Adobe-
GB1-0".

At first glance, I suppose your patch with "/"+"/" instead of "."+"]"
while init_done =3D 0 (your "gp_vms.c;2") is an attempt to workaround
this 2nd problem. However, I think it's incorrect at least for the
following reasons:

(1) It won't help if you try to read from the %rom% after all
    command-line arguments are executed. What happens if you execute
        "(*) {=3D=3D} 99 string /Encoding resourceforall"
    at the Ghostscript prompt (interactively)?
(2) A filespec built during the initialisation and stored somewhere
    won't be 100% usable later, because suddenly the separators
change.
(3) It is possible that all the job be done during the call to
    gs_main_init_with_args() that is executed with init_done =3D 0
(your
    "gs.c;2"). So, if things go well with "/"+"/" as separators, why
    do you ever need to switch back to "."+"]" ?

You should be able to get rid of the %rom% problem if you compile with
"COMPILE_INITS=3D0". There won't be any %rom% filesystem anymore, so no
need to cope with "/" as separator.

> ...
> For example, ghostscript on VMS might have a value of gs_lib:[resource]
> for GenericResourceDir.
> ...
> If GenericResourceDir ends in a ] then:
> =A0 =A01. remove the trailing ]
> ...
> If GenericResourceDir ends in a : then:
> =A0 =A01. append [ (there doesn't seem to be a variable defined for this)
> =A0 =A02. append the directory name
> ...

This is definitely wrong. GenericResourceDir must not have that exact
value and the above method, while it may be what an OpenVMS user
expects, is incorrect for PostScript. The "PostScript Language
reference Manual (3rd ed)" section C.3.6 "Resource file location"
shows how a PostScript program should construct these paths. To be
compatible with that, GenericResourceDir must be "gs_lib:[Resource."
in your example, and GenericResourcePathSep must be "]".

Somehow I live with the idea that the PostScript interpreter part of
Ghostscript expects paths to be in the form "dev:
[dir.subdir.subsubdir" (without the "]" at the end) and filenames
preceded by a partial path in the form
"subdir1.subdir2]name.ext;v" (without "[." at the beginning). I also
found a comment in gp_vms.c about an "extended =E0 la Mac OS syntax",
but don't know what this means.

****

An now, back to my original problem, that I'll explain (hope better)
here:

  - In PostScript, file-based resources are stored in a specific
directory
    structure: a base directory indicated by GenericResourceDir with
    subdirectories for the various "categories". Each resource is a
file
    stored in the subdirectory that corresponds to its category.
  - The current code, when it needs to enumerate resources of a given
    category, enumerates files twice:
    (a) as "dev:[generic.resource.dir.Category]*"
    (b) as "dev:[generic.resource.dir.Category]*]*"

The questions are:

(1) Is the 1st template enough or do we need something extra?
(2) Is the 2nd filename template useful? Even, does it make any sense?

A possible problem that I see: does (a) enumerate *ALL* files,
including those with a "." somewhere in the name+extension part? Or
does it specifically exclude those with an extension, so we must use
"dev:[generic.resource.dir.Category]*.*"?

TIA,
sags

> (b) as "dev:[generic.resource.dir.Category]*]*"

   Unbalanced brackets would, in general, be invalid.

> [...] does (a) enumerate *ALL* files, including those with
> a "." somewhere in the name+extension part?

   On VMS, _all_ files have a "."-extension/type.

>  Or does it specifically exclude those with an
> extension, so we must use
> "dev:[generic.resource.dir.Category]*.*"?

   Many things are possible, but normally "*.*" would match
more files than "*".


> The C RTL deals with Unix slash-format filenames
> mostly-fine.  Might want to try not using the native VMS
> syntax, there?

   I'm with him.  I haven't looked closely at the Ghostscript
code, but I have seen some other UNIX-oriented programs where
someone tried to define some "separator" macro as "]" to
"help" VMS, and then proceeded to use code which would work
only for UNIX-like, slash-separated paths.  If most of the
developers are VMS-unaware, then, even if it's made to work
once, trying to keep any such VMS-specific code working is
probably a doomed effort.  Most user-written
code for this purpose is of limited value.
(And that's the polite way to describe it.)

   But even with UNIX-like paths, I'd expect to use "*.*"
instead of "*".

> [...]
> probably a doomed effort.  Most user-written
> [...]

   Oops.  Lost a sentence.  That should have read:

[...]
probably a doomed effort.  Parsing VMS file specifications is
best done by VMS system service functions.  Most user-written
code for this purpose (including mine) is of limited value.
(And that's the polite way to describe it.)
[...]

On 2012-06-29 13:08:04 +0000, Steven Schweda said:

> 
>> The C RTL deals with Unix slash-format filenames
>> mostly-fine.  Might want to try not using the native VMS
>> syntax, there?
> 
>    I'm with him.

There are some zany-API VMS-to-Unix filename conversion routines around 
in the C RTL, and specifically decc$from_vms here.

(Somebody's probably also jacketed the zany-API design to something 
that can be more directly called, too.)

(And yes, decc$translate_vms helps for some cases where you'd otherwise 
have to deal with the decc$to_vms zany-API, but all that's headed in 
the wrong direction here.)

When handed a VMS-format specification somewhere, convert it to 
Unix-format immediately.

From there, the C RTL can deal with most of the Unix-format filenames 
directly.  Which simplifies the code requirements.

-- 
--
Pure Personal Opinion | HoffmanLabs LLC

On 6/29/12 2:54 AM, SaGS wrote:
> Hi and thanks for the response.
>
> I took a look at the source code in your ghostscript-9_05.zip, and I
> think you are hit by 2 problems, both completely different from mine.
>
> The 1st is that makefiles have a single macro $(D) that is used both
> as .file_name_separator ("]" on OpenVMS)
> and .file_name_directory_separator ("." on OpenVMS). The fix would be
> to define 2 macros. It's not conceptually a complicated fix, but looks
> extensive.

That is the root problem, yes.  For example, gcc supports as many 
instances of -I to specify an include directory as needed.  DECC only 
supports one instance of the /INCLUDE switch with multiple include 
directories enclosed in parens, separated by commas.  So ghostscript 
make files define the following variables for VMS:
I_=/INCLUDE=(
II=,
_I=)

On Unix they are:
I_=-I
II=-I
_I=

Then an include command line gets defined as 
$(I_)inc_dir1$(II)inc_dir2$(II)inc_dir3$(_I)

We need something similar for building paths.  Something like $(D) for 
file_name_separator and $(DD) for file_name_directory_separator.  Unix 
would define them both as "/" and VMS would define the first as "]" and 
the second as ".".  The top Unix makefile that defines directories would 
remain as it is.  The VMS makefile would define directories as dev:[dir. 
instead of the current dev:[dir] and then paths would be built as:
$(dir)$(D) or $(dir)$(D)filename or 
$(dir)$(DD)subdir1$(DD)subdir2($D)filename

> The 2nd is that the %rom% file system is built (psromfs.mak) with "/"
> hardcoded for both 2 separators; not sure how the actual device works.
> The big problem with this is the %rom% and %os% (host files) devices
> use different conventions, so functions that concatenate/ split/ etc
> filenames, and which obey the host syntax, fail with the %rom%. I
> think the correct fix is to change the %rom% to always use the same
> conventions as the host; for example you will see "%rom%
> [Resource.CMap]Adobe-GB1-0" inthere, and not "%rom%Resource/CMap/Adobe-
> GB1-0".

Actually, building the %rom device is how I solved the problem of 
finding resource files on VMS since, with the current broken code, no 
resource file could be found on VMS since about ghostscript v8.54.

> At first glance, I suppose your patch with "/"+"/" instead of "."+"]"
> while init_done = 0 (your "gp_vms.c;2") is an attempt to workaround
> this 2nd problem. However, I think it's incorrect at least for the
> following reasons:
>
> (1) It won't help if you try to read from the %rom% after all
>      command-line arguments are executed. What happens if you execute
>          "(*) {==} 99 string /Encoding resourceforall"
>      at the Ghostscript prompt (interactively)?

You get the following:
$ gs
GPL Ghostscript 9.05 (2012-02-08)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>(*) {==} 99 string /Encoding resourceforall
(SymbolEncoding)
(WinAnsiEncoding)
(StandardEncoding)
(Wingdings)
(PDFDocEncoding)
(.GS_extended_SymbolEncoding)
(DingbatsEncoding)
(MacRomanEncodingForTrueType)
(MacRomanEncoding)
(MacExpertEncoding)
(ISOLatin1Encoding)
GS>

> (2) A filespec built during the initialisation and stored somewhere
>      won't be 100% usable later, because suddenly the separators
> change.

This would be a problem if a filespec was built and saved during 
initialization and then appended to sometime after init is complete.  I 
have found no instances of this.

> (3) It is possible that all the job be done during the call to
>      gs_main_init_with_args() that is executed with init_done = 0
> (your
>      "gs.c;2"). So, if things go well with "/"+"/" as separators, why
>      do you ever need to switch back to "."+"]" ?

For backwards compatibility.  For one, I didn't know if there was 
anything in the code that depended on VMS parsing (when running on VMS) 
after init was done.  Also, what if someone was using a postscript file 
that assumed the presence of the existing VMS parsing rules?

> You should be able to get rid of the %rom% problem if you compile with
> "COMPILE_INITS=0". There won't be any %rom% filesystem anymore, so no
> need to cope with "/" as separator.

See above answer.  COMPILE_INITS is currently solving a problem, not 
causing one.

>> ...
>> For example, ghostscript on VMS might have a value of gs_lib:[resource]
>> for GenericResourceDir.
>> ...
>> If GenericResourceDir ends in a ] then:
>>     1. remove the trailing ]
>> ...
>> If GenericResourceDir ends in a : then:
>>     1. append [ (there doesn't seem to be a variable defined for this)
>>     2. append the directory name
>> ...
>
> This is definitely wrong. GenericResourceDir must not have that exact
> value and the above method, while it may be what an OpenVMS user
> expects, is incorrect for PostScript. The "PostScript Language
> reference Manual (3rd ed)" section C.3.6 "Resource file location"
> shows how a PostScript program should construct these paths. To be
> compatible with that, GenericResourceDir must be "gs_lib:[Resource."
> in your example, and GenericResourcePathSep must be "]".
>
> Somehow I live with the idea that the PostScript interpreter part of
> Ghostscript expects paths to be in the form "dev:
> [dir.subdir.subsubdir" (without the "]" at the end) and filenames
> preceded by a partial path in the form
> "subdir1.subdir2]name.ext;v" (without "[." at the beginning). I also
> found a comment in gp_vms.c about an "extended � la Mac OS syntax",
> but don't know what this means.

Ghostscript is documented as not being compliant with the PLRM since the 
PLRM uses a single resource directory but ghostscript uses multiple 
directories for resources.  It also documents the use of absolute 
filenames and relative filenames but not partial filenames.

I'll throw together a build without the %rom filesystem so I can 
explicitly describe what is currently going on with VMS filename parsing 
rather than trying to depend on memory.

>
> ****
>
> An now, back to my original problem, that I'll explain (hope better)
> here:
>
>    - In PostScript, file-based resources are stored in a specific
> directory
>      structure: a base directory indicated by GenericResourceDir with
>      subdirectories for the various "categories". Each resource is a
> file
>      stored in the subdirectory that corresponds to its category.
>    - The current code, when it needs to enumerate resources of a given
>      category, enumerates files twice:
>      (a) as "dev:[generic.resource.dir.Category]*"
>      (b) as "dev:[generic.resource.dir.Category]*]*"
>
> The questions are:
>
> (1) Is the 1st template enough or do we need something extra?
> (2) Is the 2nd filename template useful? Even, does it make any sense?

Specifying two closing brackets in any VMS file specification will 
always be an error (note than an escaped bracket, i.e. ^], is not 
considered a closing bracket in this context).

> A possible problem that I see: does (a) enumerate *ALL* files,
> including those with a "." somewhere in the name+extension part? Or
> does it specifically exclude those with an extension, so we must use
> "dev:[generic.resource.dir.Category]*.*"?

Change this so it reads dev:[generic_resource_dir.Category]* and you 
will be correct.  As written you have a directory tree 4 levels deep.

* works just as well as *.* to enumerate all files.  At least it does in 
everything I've ever tested.  Here is an example:

(this command says search every file in the directory and return the 
filename of any file that does not contain the search string xxx).

$ sear * xxx/match=nor/wind=0
FREEWARE:[BUILD.php5]php-5^.2^.13.DIR;1
FREEWARE:[BUILD.php5]php-5^.3^.10.DIR;1
FREEWARE:[BUILD.php5]php-5^.3^.13.DIR;1
FREEWARE:[BUILD.php5]php-5^.3^.14.DIR;1
FREEWARE:[BUILD.php5]php-5^.3^.6.DIR;1

The result is every file in the directory even though they contain 
multiple dots in the file name.  I get the same results when I test with 
glob.

Mark Berryman

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 2012-06-29 19:37:29 +0000, Mark Berryman said:

> On 6/29/12 2:54 AM, SaGS wrote:
>> Hi and thanks for the response.
>> 
>> I took a look at the source code in your ghostscript-9_05.zip, and I
>> think you are hit by 2 problems, both completely different from mine.
>> 
>> The 1st is that makefiles have a single macro $(D) that is used both
>> as .file_name_separator ("]" on OpenVMS)
>> and .file_name_directory_separator ("." on OpenVMS). The fix would be
>> to define 2 macros. It's not conceptually a complicated fix, but looks
>> extensive.
> 
> That is the root problem, yes.  For example, gcc supports as many 
> instances of -I to specify an include directory as needed.  DECC only 
> supports one instance of the /INCLUDE switch with multiple include 
> directories enclosed in parens, separated by commas.  So ghostscript 
> make files define the following variables for VMS:
> ...
> Then an include command line gets defined as 
> $(I_)inc_dir1$(II)inc_dir2$(II)inc_dir3$(_I)
> 
> We need something similar for building paths.


See HELP CC /INCLUDE_DIRECTORY for details of how to combine that 
qualifier with the DECC$USER_INCLUDE, DECC$SYSTEM_INCLUDE and 
DECC$LIBRARY_INCLUDE logical names, as well as with various known 
directories.

And those logical names accept Unix-format filenames, as well as native 
VMS filenames.

The gnv cc wrapper also plays around in this same area, though that 
operates in its own and inimitable fashion.

-- 
--
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman wrote:
> On 2012-06-29 13:08:04 +0000, Steven Schweda said:
> 
>>
>>> The C RTL deals with Unix slash-format filenames
>>> mostly-fine.  Might want to try not using the native VMS
>>> syntax, there?
>>
>>    I'm with him.
> 
> There are some zany-API VMS-to-Unix filename conversion routines around 
> in the C RTL, and specifically decc$from_vms here.
> 
> (Somebody's probably also jacketed the zany-API design to something that 
> can be more directly called, too.)
> 
> (And yes, decc$translate_vms helps for some cases where you'd otherwise 
> have to deal with the decc$to_vms zany-API, but all that's headed in the 
> wrong direction here.)
> 
> When handed a VMS-format specification somewhere, convert it to 
> Unix-format immediately.
> 
>  From there, the C RTL can deal with most of the Unix-format filenames 
> directly.  Which simplifies the code requirements.
> 

The really good reason to have such in the C RTL is that if you use any other language 
you're screwed.  Too bad it wasn't implemented in a generic RTL such as LIB$.

But hey, it's just my minority opinion, don't worry about it ....

On 2012-06-29 20:30:30 +0000, David Froble said:

> Stephen Hoffman wrote:
>> There are some zany-API VMS-to-Unix filename conversion routines around 
>> in the C RTL, and specifically decc$from_vms here.
> 
> The really good reason to have such in the C RTL is that if you use any 
> other language you're screwed.  Too bad it wasn't implemented in a 
> generic RTL such as LIB$.
> 
> But hey, it's just my minority opinion, don't worry about it ....

The native C APIs do differ from native VMS APIs.  Which can confound 
folks accustomed to Fortran, BASIC and other languages.

The particular APIs provided for the C RTL decc$from_vms and 
decc$to_vms filename conversion routines are unconventional and 
ideosyncratic.  Even for C APIs.


-- 
--
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman wrote:
> On 2012-06-29 20:30:30 +0000, David Froble said:
> 
>> Stephen Hoffman wrote:
>>> There are some zany-API VMS-to-Unix filename conversion routines 
>>> around in the C RTL, and specifically decc$from_vms here.
>>
>> The really good reason to have such in the C RTL is that if you use 
>> any other language you're screwed.  Too bad it wasn't implemented in a 
>> generic RTL such as LIB$.
>>
>> But hey, it's just my minority opinion, don't worry about it ....
> 
> The native C APIs do differ from native VMS APIs.  Which can confound 
> folks accustomed to Fortran, BASIC and other languages.
> 
> The particular APIs provided for the C RTL decc$from_vms and decc$to_vms 
> filename conversion routines are unconventional and ideosyncratic.  Even 
> for C APIs.
> 
> 

:-)

And here I thought I was going to get "nailed" because the stuff was in LIB$ routines. 
Even as I typed, I thought that I should check, but meh, too much like work.

:-)

On Jun 29, 10:37=A0pm, Mark Berryman <m...@theberrymans.com> wrote:
> ...
>>          "(*) {=3D=3D} 99 string /Encoding resourceforall"
> ...
>
> You get the following:
> $ gs
> GPL Ghostscript 9.05 (2012-02-08)
> Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
> GS>(*) {=3D=3D} 99 string /Encoding resourceforall
> (SymbolEncoding)
> (WinAnsiEncoding)
> (StandardEncoding)
> (Wingdings)
> (PDFDocEncoding)
> (.GS_extended_SymbolEncoding)
> (DingbatsEncoding)
> (MacRomanEncodingForTrueType)
> (MacRomanEncoding)
> (MacExpertEncoding)
> (ISOLatin1Encoding)
> GS>

I apologize, bad example. With Ghostscript, the /Encoding resources
are particular: all of these are predefined except Wingdings which is
always loaded during the initialization. So, they will be found (in
VM) even if %rom% access doesn't work any more.

Try with the /CMap category instead of /Encoding, but take care CMaps
are not accessible from the disk too.

You can also test

    (Adobe-GB1-0) /CMap resourcestatus pstack clear

(from the GS> prompt; be sure the CMaps are not available on disk
too). You should get "true some_number 2". If you get "false", then
the resource was not found indicating that %rom% access doesn't work.
It you get 0 or 1 instead of 2, it means the resource is already
loaded (no reason for it to be, immediately after startup), so the
test isn't meaningful.

> ...
>> (3) It is possible that all the job be done during the call to
>>     gs_main_init_with_args() that is executed with init_done =3D 0
>>     (your "gs.c;2"). So, if things go well with "/"+"/" as separators,
>>     why do you ever need to switch back to "."+"]" ?
>
> For backwards compatibility.  For one, I didn't know if there was
> anything in the code that depended on VMS parsing (when running on VMS)
> after init was done.  Also, what if someone was using a postscript file
> that assumed the presence of the existing VMS parsing rules?

OK. My point was that it's possible that *ALL* the job is done with
"/"+"/" in effect (during that gs_main_init_with_args() call). If you
pass the PostScript code via stdin then that code will see "."+"]";
code in files passed on the command line will see "/"+"/". (I cannot
test any of this, so maybe I'm wrong...)

> ...
> Specifying two closing brackets in any VMS file specification will
> always be an error (note than an escaped bracket, i.e. ^], is not
> considered a closing bracket in this context).
> ...
> * works just as well as *.* to enumerate all files.  At least it does in
> everything I've ever tested.
> ...

Thanks a lot, this is exactly what I needed clarified.

sags

On 6/29/12 2:14 PM, Stephen Hoffman wrote:
> On 2012-06-29 19:37:29 +0000, Mark Berryman said:
>
>> On 6/29/12 2:54 AM, SaGS wrote:
>>> Hi and thanks for the response.
>>>
>>> I took a look at the source code in your ghostscript-9_05.zip, and I
>>> think you are hit by 2 problems, both completely different from mine.
>>>
>>> The 1st is that makefiles have a single macro $(D) that is used both
>>> as .file_name_separator ("]" on OpenVMS)
>>> and .file_name_directory_separator ("." on OpenVMS). The fix would be
>>> to define 2 macros. It's not conceptually a complicated fix, but looks
>>> extensive.
>>
>> That is the root problem, yes.  For example, gcc supports as many
>> instances of -I to specify an include directory as needed.  DECC only
>> supports one instance of the /INCLUDE switch with multiple include
>> directories enclosed in parens, separated by commas.  So ghostscript
>> make files define the following variables for VMS:
>> ...
>> Then an include command line gets defined as
>> $(I_)inc_dir1$(II)inc_dir2$(II)inc_dir3$(_I)
>>
>> We need something similar for building paths.
>
>
> See HELP CC /INCLUDE_DIRECTORY for details of how to combine that
> qualifier with the DECC$USER_INCLUDE, DECC$SYSTEM_INCLUDE and
> DECC$LIBRARY_INCLUDE logical names, as well as with various known
> directories.

Ghostscript uses a common set of make files for all of the platforms it 
builds on.  These make files are going to have the include directories 
in their action lines since that is the only common way for the 
compilers on all platforms to get that info.  This pretty much means 
there needs to be an available syntax for the DECC command line and also 
precludes the use of logical names.

> And those logical names accept Unix-format filenames, as well as native
> VMS filenames.

Would you mind providing the magic incantation for that?  I've never 
been able to get a unix-formatted include path to work in a logical name 
although the exact same path works fine in the command line.

[remainder removed]

Mark Berryman

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 6/30/12 7:18 AM, SaGS wrote:
> On Jun 29, 10:37 pm, Mark Berryman <m...@theberrymans.com> wrote:
>> ...
>>>           "(*) {==} 99 string /Encoding resourceforall"
>> ...
>>
>> You get the following:
>> $ gs
>> GPL Ghostscript 9.05 (2012-02-08)
>> Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
>> This software comes with NO WARRANTY: see the file PUBLIC for details.
>> GS>(*) {==} 99 string /Encoding resourceforall
>> (SymbolEncoding)
>> (WinAnsiEncoding)
>> (StandardEncoding)
>> (Wingdings)
>> (PDFDocEncoding)
>> (.GS_extended_SymbolEncoding)
>> (DingbatsEncoding)
>> (MacRomanEncodingForTrueType)
>> (MacRomanEncoding)
>> (MacExpertEncoding)
>> (ISOLatin1Encoding)
>> GS>
>
> I apologize, bad example. With Ghostscript, the /Encoding resources
> are particular: all of these are predefined except Wingdings which is
> always loaded during the initialization. So, they will be found (in
> VM) even if %rom% access doesn't work any more.
>
> Try with the /CMap category instead of /Encoding, but take care CMaps
> are not accessible from the disk too.
>
> You can also test
>
>      (Adobe-GB1-0) /CMap resourcestatus pstack clear
>
> (from the GS> prompt; be sure the CMaps are not available on disk
> too). You should get "true some_number 2". If you get "false", then
> the resource was not found indicating that %rom% access doesn't work.
> It you get 0 or 1 instead of 2, it means the resource is already
> loaded (no reason for it to be, immediately after startup), so the
> test isn't meaningful.
>
>> ...
>>> (3) It is possible that all the job be done during the call to
>>>      gs_main_init_with_args() that is executed with init_done = 0
>>>      (your "gs.c;2"). So, if things go well with "/"+"/" as separators,
>>>      why do you ever need to switch back to "."+"]" ?
>>
>> For backwards compatibility.  For one, I didn't know if there was
>> anything in the code that depended on VMS parsing (when running on VMS)
>> after init was done.  Also, what if someone was using a postscript file
>> that assumed the presence of the existing VMS parsing rules?
>
> OK. My point was that it's possible that *ALL* the job is done with
> "/"+"/" in effect (during that gs_main_init_with_args() call). If you
> pass the PostScript code via stdin then that code will see "."+"]";
> code in files passed on the command line will see "/"+"/". (I cannot
> test any of this, so maybe I'm wrong...)
[text deleted]

I've done quite a bit of testing since this question was posed.

First, the problem that arises when building on VMS without the %rom 
device is that the init file GS_RES.PS tries to find all of the other 
resource files by using its own filename as the starting path (e.g. 
gs_res.ps]x]y ).  I have yet to be able to determine why it is using its 
own filename instead of the path to its own filename.  When I do, this 
particular issue will be easy to fix.

Next, in all of my testing, I cannot find any instance where Ghostscript 
finds anything in the VMS filesystem using gp_file_name_separator other 
than when trying to look up a resource file.  If all of the resource 
files are located in the %rom device, then gp_file_name_separator never 
wants to be anything but a "/".

Next, ghostscript has code that needs to be able to enumerate files in a 
directory.  The OS support code gets passed a string with a wildcard in 
it and that code must be able to return all files matching the wild 
card.  VMS currently uses LIB$FIND_FILE for this.  I tried adding 
detection of a unix format filename and using DECC$TO_VMS in that case. 
  Unfortunately DECC$TO_VMS is badly broken when passed a wild card 
argument (./dir1/dir2/dir3/* returns only [.dir3]filename).  This 
precludes converting everything inside ghostscript to simply be in unix 
format.

So, the solution that seems to solve everything, for now, for building 
Ghostscript on VMS is to build all of the resource files into the %rom 
device and leave the file separation characters defined in Unix format. 
  This allows ghostscript to continue to find files in the %rom device 
after initialization but doesn't affect the ability to be given 
VMS-formatted filenames as commands or arguments.

As a final note, the next kit will have x11alpha as the default output 
device instead of x11.  The display quality on x11alpha is much better 
than with x11.

Mark Berryman


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

"Mark Berryman" <mark@theberrymans.com> wrote in message
news:jt69c2$5da$1@adenine.netfront.net...
> ...
>> You can also test
>>
>>      (Adobe-GB1-0) /CMap resourcestatus pstack clear
>>
>> (from the GS> prompt; be sure the CMaps are not available on disk
>> too). You should get "true some_number 2". If you get "false", then
>> the resource was not found indicating that %rom% access doesn't work.
>> It you get 0 or 1 instead of 2, it means the resource is already
>> loaded (no reason for it to be, immediately after startup), so the
>> test isn't meaningful.

Please try the above. I think the result will be that, with the
current set
of patches, %rom% isn't accessible after commandline argument are
processed.
In particular far-east fonts (which need CMaps) won't work when
passing
the PostScript code via stdin or at the GS> prompt.

> ...
> First, the problem that arises when building on VMS without the %rom
> device is that the init file GS_RES.PS tries to find all of the other
> resource files by using its own filename as the starting path (e.g.
> gs_res.ps]x]y ).

I find this very strange, and as you describe it it seems to be a bug
that needs fixing.

For the moment I partially hacked Windows GS to use OpenVMS syntax in
filenames. It works with the %rom%, but it's much more to do before
it
will be able to access files on disk. When/if I'll hack it better I'll
see if I can reproduce the problem and eventually fix it.

> ...
> Next, in all of my testing, I cannot find any instance where Ghostscript
> finds anything in the VMS filesystem using gp_file_name_separator other
> than when trying to look up a resource file.

Not so surprising, because the PostScript language does not define
"directories" at all, the abstract filesystem it uses is flat.
However,
you cannot know what user PostScript code (and eventually GS's PDF
interpreter, which is written in PostScript) does...

> If all of the resource
> files are located in the %rom device, then gp_file_name_separator never
> wants to be anything but a "/".
> ...
> I tried adding detection of a unix format filename and using
> DECC$TO_VMS in that case. Unfortunately DECC$TO_VMS is badly broken
> when passed a wild card argument (./dir1/dir2/dir3/* returns only
> [.dir3]filename).  This precludes converting everything inside
> ghostscript to simply be in unix format.
> ...

Here are some changes to make the %rom% filename syntax compatible
with
the OpenVMS one - remove the hardcoded "/"+"/" and use "."+"]"
instead.

FIRST, I found a genuine bug that hinders finding standard fonts
automatically on OpenVMS, independent of whether we build with the
%rom% device or not. This bug has no effect on other platforms,
because
there the 2 dir+file separators are the same.

>8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 --
OpenVMS: wrong separator in defining the Font resource directory.

diff --git a/gs/Resource/Init/gs_res.ps b/gs/Resource/Init/gs_res.ps
index f836f20..e8e69bc 100644
--- a/gs/Resource/Init/gs_res.ps
+++ b/gs/Resource/Init/gs_res.ps
@@ -302,7 +302,7 @@ systemdict begin
      systemdict 1 index undef
    } {
      dup () ne {
-     .file_name_directory_separator concatstrings
+     .file_name_separator concatstrings
     } if
     2 index exch //false .file_name_combine not {
       (Error: .default_resource_dir returned ) print exch print
( that can't combine with ) print =
>8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 --

Note that a few lines after those affected by the preceding patch
there
are 2 strings with hardcoded "/". I haven't found these used, so I
would
not be worried about them for the moment. Of course there may be other
bugs
too, I'll post here if/when I'll have more info (although it's
annoying I
cannot attach patch files to messages posted here).


NEXT, it seems I found the way to make the %rom% path syntax the same
as the one used by the host (OpemVMS). I simulated the situation by
hacking the Windows version, and it works: is able to automatically
find
%rom% resources, including fonts, using the OpenVMS separators
"."+"]".

Here's the idea:

>8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 --
OpenVMS: Example for getting OpenVMS-like paths for the %rom% device.
- Before this patch, the %rom% filesystem had the file/ directory
  separators hardcoded as "/"; now %rom% full filenames look like
  "%rom%[dir.subdir.subsubdir]filename.ext", similar to the host %os%
  paths except there's no "dev:[root.]" part (not usefull there).

diff --git a/gs/base/lib.mak b/gs/base/lib.mak
index c09d90e..d2eb50b 100644
--- a/gs/base/lib.mak
+++ b/gs/base/lib.mak
@@ -3061,13 +3061,13 @@ $(GLD)romfs0.dev :  $(LIB_MAK) $(ECHOGS_XE)

 $(GLGEN)gsromfs1_.c : $(MKROMFS_XE) $(PS_ROMFS_DEPS) $(MAKEDIRS)
 	$(EXP)$(MKROMFS_XE) -o $(GLGEN)gsromfs1_.c \
-	-X .svn -X CVS -P $(GLSRCDIR)$(D)..$(D) iccprofiles$(D)* \
+	-X .svn -X CVS -d "[iccprofiles]" -P $(GLSRCDIR)$(D)..$(D)iccprofiles
$(D) * \
 	$(PCLXL_ROMFS_ARGS) $(PJL_ROMFS_ARGS) $(XPS_ROMFS_ARGS) \
 	$(PS_ROMFS_ARGS) $(GL_ROMFS_ARGS)

 $(GLGEN)gsromfs1_1.c : $(MKROMFS_XE) $(PS_ROMFS_DEPS) $(MAKEDIRS)
 	$(EXP)$(MKROMFS_XE) -o $(GLGEN)gsromfs1_1.c \
-	-X .svn -X CVS -P $(GLSRCDIR)$(D)..$(D) iccprofiles$(D)* \
+	-X .svn -X CVS -d "[iccprofiles]" -P $(GLSRCDIR)$(D)..$(D)iccprofiles
$(D) * \
 	$(UFST_ROMFS_ARGS) $(PCLXL_ROMFS_ARGS) $(PJL_ROMFS_ARGS) $
(XPS_ROMFS_ARGS) \
 	$(PS_ROMFS_ARGS) $(GL_ROMFS_ARGS)


diff --git a/gs/psi/psromfs.mak b/gs/psi/psromfs.mak
index 5249748..33fd352 100644
--- a/gs/psi/psromfs.mak
+++ b/gs/psi/psromfs.mak
@@ -37,6 +37,26 @@ PS_ROMFS_ARGS=-c \
   -d Resource/ -P $(PSRESDIR)$(D) $(RESOURCE_LIST) \
   -d lib/ -P $(PSLIBDIR)$(D) $(EXTRA_INIT_FILES)

+# OpenVMS-like %rom% paths
+PS_ROMFS_ARGS= \
+  -c \
+  -d "[Resource.Init]"       -P $(PSRESDIR)$(D)Init$(D) -g gs_init.ps
$(gconfig_h) \
+  -d "[Resource.CIDFSubst]"  -P $(PSRESDIR)$(D)CIDFSubst$(D) * \
+  -d "[Resource.CIDFont]"    -P $(PSRESDIR)$(D)CIDFont$(D)* \
+  -C \
+  -d "[Resource.CMap]"       -P $(PSRESDIR)$(D)CMap$(D) * \
+  -d "[Resource.ColorSpace]" -P $(PSRESDIR)$(D)ColorSpace$(D) * \
+  -d "[Resource.Decoding]"   -P $(PSRESDIR)$(D)Decoding$(D) * \
+  -d "[Resource.Encoding]"   -P $(PSRESDIR)$(D)Encoding$(D) * \
+  -B -b \
+  -d "[Resource.Font]"       -P $(PSRESDIR)$(D)Font$(D) * \
+  -c -C \
+  -d "[Resource.IdiomSet]"   -P $(PSRESDIR)$(D)IdiomSet$(D) * \
+  -d "[Resource.ProcSet]"    -P $(PSRESDIR)$(D)ProcSet$(D) * \
+  -B \
+  -d "[Resource.Init]"       -P $(PSRESDIR)$(D)Init$(D) $
(MISC_INIT_FILES) \
+  -d "[lib]"                 -P $(PSLIBDIR)$(D) $(EXTRA_INIT_FILES)
+
 # If you add a file remember to add it here. If you forget then
builds from
 # clean will work (as all files in the directory are included), but
rebuilds
 # after changes to unlisted files will not cause the romfs to be
regenerated.
>8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 --

This is only an example, you need to adapt it for "true" OpenVMS:
(a) The path after "-P" should be as needed for the host used to build
GS.
    So some "$(D)" ithere must actually be directory separators ".".
(b) I modified psromfs.mak (used for Windows), but this does not seem
used
    for OpenVMS. Instead, openvms.mak overrides the PS_ROMFS_ARGS=
macro, so
    modify it there.

The idea here is to

- use "-P" to tell it where to look on disk for the source files, and
  put there the *whole* directory part; never put (sub)directories
  in the template;
- use "-d" to set the %rom% prefix (the "directory" part) you want.

WHAT YOU GAIN is that you do not need to use Unix-style paths at all.

- cancel the addition of "init_done" and the tricks with the dir+file
  separators, letting them always be the OpenVMS ones;
- standard fonts will be found automatically, no need to list them
all
  in Fontmap.VMS.
- CMaps (and other resources) will be found automatically in %rom%
when
  needed, even after all command-line arguments have been processed
(eg
  if passing PostScript code via stdin or typing at the GS> prompt -
  I don't think this works with your current set of patches).

Hope that helps,
sags

On 7/9/12 5:39 AM, SaGS wrote:
> "Mark Berryman" <mark@theberrymans.com> wrote in message
> news:jt69c2$5da$1@adenine.netfront.net...
>> ...
>>> You can also test
>>>
>>>       (Adobe-GB1-0) /CMap resourcestatus pstack clear
>>>
>>> (from the GS> prompt; be sure the CMaps are not available on disk
>>> too). You should get "true some_number 2". If you get "false", then
>>> the resource was not found indicating that %rom% access doesn't work.
>>> It you get 0 or 1 instead of 2, it means the resource is already
>>> loaded (no reason for it to be, immediately after startup), so the
>>> test isn't meaningful.
>
> Please try the above. I think the result will be that, with the
> current set
> of patches, %rom% isn't accessible after commandline argument are
> processed.
> In particular far-east fonts (which need CMaps) won't work when
> passing
> the PostScript code via stdin or at the GS> prompt.

$ gs
GPL Ghostscript 9.05 (2012-02-08)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>(Adobe-GB1-0) /CMap resourcestatus pstack clear
true
-1
2
GS>

>
>> ...
>> First, the problem that arises when building on VMS without the %rom
>> device is that the init file GS_RES.PS tries to find all of the other
>> resource files by using its own filename as the starting path (e.g.
>> gs_res.ps]x]y ).
>
> I find this very strange, and as you describe it it seems to be a bug
> that needs fixing.

Yes, it is definitely a bug.  I'm still trying to find it in the code.

>
> For the moment I partially hacked Windows GS to use OpenVMS syntax in
> filenames. It works with the %rom%, but it's much more to do before
> it
> will be able to access files on disk. When/if I'll hack it better I'll
> see if I can reproduce the problem and eventually fix it.
>
>> ...
>> Next, in all of my testing, I cannot find any instance where Ghostscript
>> finds anything in the VMS filesystem using gp_file_name_separator other
>> than when trying to look up a resource file.
>
> Not so surprising, because the PostScript language does not define
> "directories" at all, the abstract filesystem it uses is flat.
> However,
> you cannot know what user PostScript code (and eventually GS's PDF
> interpreter, which is written in PostScript) does...

Sort of.  There is certainly an edge case here that needs to be fixed 
and it looks like we are both trying to do so.  However, 99+% of all .ps 
and .pdf files will fall into one of the following categories:

1. does not do any path building
2. does path building but was written on a non-vms system and assumes 
one can simply concatenate path elements.  The result will be a 
unix-format path name which will work on VMS.
3. was written on VMS and does VMS path building.  Such code would not 
try to do the same thing that gs_res.ps does as it would know the right 
way to build a VMS path.

The edge case would be something other than gs_res.ps trying to work the 
same way gs_res.ps does (rather than just providing the name of a 
resource and saying "go find it" - which would work).  This I'd still 
like to get fixed.
>
>> If all of the resource
>> files are located in the %rom device, then gp_file_name_separator never
>> wants to be anything but a "/".
>> ...
>> I tried adding detection of a unix format filename and using
>> DECC$TO_VMS in that case. Unfortunately DECC$TO_VMS is badly broken
>> when passed a wild card argument (./dir1/dir2/dir3/* returns only
>> [.dir3]filename).  This precludes converting everything inside
>> ghostscript to simply be in unix format.
>> ...
>
> Here are some changes to make the %rom% filename syntax compatible
> with
> the OpenVMS one - remove the hardcoded "/"+"/" and use "."+"]"
> instead.
>
> FIRST, I found a genuine bug that hinders finding standard fonts
> automatically on OpenVMS, independent of whether we build with the
> %rom% device or not. This bug has no effect on other platforms,
> because
> there the 2 dir+file separators are the same.
>
>> 8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 --
> OpenVMS: wrong separator in defining the Font resource directory.
>
> diff --git a/gs/Resource/Init/gs_res.ps b/gs/Resource/Init/gs_res.ps
> index f836f20..e8e69bc 100644
> --- a/gs/Resource/Init/gs_res.ps
> +++ b/gs/Resource/Init/gs_res.ps
> @@ -302,7 +302,7 @@ systemdict begin
>        systemdict 1 index undef
>      } {
>        dup () ne {
> -     .file_name_directory_separator concatstrings
> +     .file_name_separator concatstrings
>       } if
>       2 index exch //false .file_name_combine not {
>         (Error: .default_resource_dir returned ) print exch print
> ( that can't combine with ) print =
>> 8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 --
>
> Note that a few lines after those affected by the preceding patch
> there
> are 2 strings with hardcoded "/". I haven't found these used, so I
> would
> not be worried about them for the moment. Of course there may be other
> bugs
> too, I'll post here if/when I'll have more info (although it's
> annoying I
> cannot attach patch files to messages posted here).
>
>
> NEXT, it seems I found the way to make the %rom% path syntax the same
> as the one used by the host (OpemVMS). I simulated the situation by
> hacking the Windows version, and it works: is able to automatically
> find
> %rom% resources, including fonts, using the OpenVMS separators
> "."+"]".
>
> Here's the idea:
>
>> 8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 --
> OpenVMS: Example for getting OpenVMS-like paths for the %rom% device.
> - Before this patch, the %rom% filesystem had the file/ directory
>    separators hardcoded as "/"; now %rom% full filenames look like
>    "%rom%[dir.subdir.subsubdir]filename.ext", similar to the host %os%
>    paths except there's no "dev:[root.]" part (not usefull there).
>
> diff --git a/gs/base/lib.mak b/gs/base/lib.mak
> index c09d90e..d2eb50b 100644
> --- a/gs/base/lib.mak
> +++ b/gs/base/lib.mak
> @@ -3061,13 +3061,13 @@ $(GLD)romfs0.dev :  $(LIB_MAK) $(ECHOGS_XE)
>
>   $(GLGEN)gsromfs1_.c : $(MKROMFS_XE) $(PS_ROMFS_DEPS) $(MAKEDIRS)
>   	$(EXP)$(MKROMFS_XE) -o $(GLGEN)gsromfs1_.c \
> -	-X .svn -X CVS -P $(GLSRCDIR)$(D)..$(D) iccprofiles$(D)* \
> +	-X .svn -X CVS -d "[iccprofiles]" -P $(GLSRCDIR)$(D)..$(D)iccprofiles
> $(D) * \
>   	$(PCLXL_ROMFS_ARGS) $(PJL_ROMFS_ARGS) $(XPS_ROMFS_ARGS) \
>   	$(PS_ROMFS_ARGS) $(GL_ROMFS_ARGS)
>
>   $(GLGEN)gsromfs1_1.c : $(MKROMFS_XE) $(PS_ROMFS_DEPS) $(MAKEDIRS)
>   	$(EXP)$(MKROMFS_XE) -o $(GLGEN)gsromfs1_1.c \
> -	-X .svn -X CVS -P $(GLSRCDIR)$(D)..$(D) iccprofiles$(D)* \
> +	-X .svn -X CVS -d "[iccprofiles]" -P $(GLSRCDIR)$(D)..$(D)iccprofiles
> $(D) * \
>   	$(UFST_ROMFS_ARGS) $(PCLXL_ROMFS_ARGS) $(PJL_ROMFS_ARGS) $
> (XPS_ROMFS_ARGS) \
>   	$(PS_ROMFS_ARGS) $(GL_ROMFS_ARGS)
>
>
> diff --git a/gs/psi/psromfs.mak b/gs/psi/psromfs.mak
> index 5249748..33fd352 100644
> --- a/gs/psi/psromfs.mak
> +++ b/gs/psi/psromfs.mak
> @@ -37,6 +37,26 @@ PS_ROMFS_ARGS=-c \
>     -d Resource/ -P $(PSRESDIR)$(D) $(RESOURCE_LIST) \
>     -d lib/ -P $(PSLIBDIR)$(D) $(EXTRA_INIT_FILES)
>
> +# OpenVMS-like %rom% paths
> +PS_ROMFS_ARGS= \
> +  -c \
> +  -d "[Resource.Init]"       -P $(PSRESDIR)$(D)Init$(D) -g gs_init.ps
> $(gconfig_h) \
> +  -d "[Resource.CIDFSubst]"  -P $(PSRESDIR)$(D)CIDFSubst$(D) * \
> +  -d "[Resource.CIDFont]"    -P $(PSRESDIR)$(D)CIDFont$(D)* \
> +  -C \
> +  -d "[Resource.CMap]"       -P $(PSRESDIR)$(D)CMap$(D) * \
> +  -d "[Resource.ColorSpace]" -P $(PSRESDIR)$(D)ColorSpace$(D) * \
> +  -d "[Resource.Decoding]"   -P $(PSRESDIR)$(D)Decoding$(D) * \
> +  -d "[Resource.Encoding]"   -P $(PSRESDIR)$(D)Encoding$(D) * \
> +  -B -b \
> +  -d "[Resource.Font]"       -P $(PSRESDIR)$(D)Font$(D) * \
> +  -c -C \
> +  -d "[Resource.IdiomSet]"   -P $(PSRESDIR)$(D)IdiomSet$(D) * \
> +  -d "[Resource.ProcSet]"    -P $(PSRESDIR)$(D)ProcSet$(D) * \
> +  -B \
> +  -d "[Resource.Init]"       -P $(PSRESDIR)$(D)Init$(D) $
> (MISC_INIT_FILES) \
> +  -d "[lib]"                 -P $(PSLIBDIR)$(D) $(EXTRA_INIT_FILES)
> +
>   # If you add a file remember to add it here. If you forget then
> builds from
>   # clean will work (as all files in the directory are included), but
> rebuilds
>   # after changes to unlisted files will not cause the romfs to be
> regenerated.
>> 8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 --
>
> This is only an example, you need to adapt it for "true" OpenVMS:
> (a) The path after "-P" should be as needed for the host used to build
> GS.
>      So some "$(D)" ithere must actually be directory separators ".".
> (b) I modified psromfs.mak (used for Windows), but this does not seem
> used
>      for OpenVMS. Instead, openvms.mak overrides the PS_ROMFS_ARGS=
> macro, so
>      modify it there.
>
> The idea here is to
>
> - use "-P" to tell it where to look on disk for the source files, and
>    put there the *whole* directory part; never put (sub)directories
>    in the template;
> - use "-d" to set the %rom% prefix (the "directory" part) you want.
>
> WHAT YOU GAIN is that you do not need to use Unix-style paths at all.

The main reason I did not build the %rom device with VMS syntax is that 
there is code in ghostscript that assumes it is in unix syntax.  The 
following two lines are samples.

code = file_path_add(minst, &minst->lib_path, "%rom%Resource/Init/");
code = file_path_add(minst, &minst->lib_path, "%rom%lib/");

There are others and I was trying to avoid making a lot of VMS-specific 
changes to the code.

That being said, I certainly have no object to leaving everything in VMS 
syntax once the bug in gs_res.ps is found and fixed.  Until it is, too 
many things fail to get found when searching for resources in VMS syntax.

>
> - cancel the addition of "init_done" and the tricks with the dir+file
>    separators, letting them always be the OpenVMS ones;
> - standard fonts will be found automatically, no need to list them
> all
>    in Fontmap.VMS.
> - CMaps (and other resources) will be found automatically in %rom%
> when
>    needed, even after all command-line arguments have been processed
> (eg
>    if passing PostScript code via stdin or typing at the GS> prompt -
>    I don't think this works with your current set of patches).

As I think I mentioned in my last message, the current set of patches 
has been updated.  Init_done is gone.  Currently, everything is being 
properly found.

> Hope that helps,

It's been a lot of help.  Thanks.  The only thing I really have left to 
do is find the bug in gs_res.ps.

Mark Berryman

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

I found the bug, well, bugs actually.

There are two errors in gs_res.ps, one of which has already been noted. 
  Here is the original code (which will probably wrap):

%  <path> <name> <string> .resource_dir_name <path> <name> <string>
/.resource_dir_name
{  systemdict 2 index .knownget {
      exch pop
      systemdict 1 index undef
    } {
      dup () ne {
      .file_name_directory_separator concatstrings
     } if
     2 index exch //false .file_name_combine not {
       (Error: .default_resource_dir returned ) print exch print ( that 
can't combine with ) print =
       /.default_resource_dir cvx /configurationerror signalerror
     } if
   } ifelse
} bind def


currentdict /pssystemparams known not {
   /pssystemparams 10 dict readonly def
} if
pssystemparams begin
   .default_resource_dir
   /FontResourceDir (Font) .resource_dir_name
      readonly .forcedef % pssys'params is r-o
   /GenericResourceDir () .resource_dir_name
      readonly .forcedef % pssys'params is r-o
   pop % .default_resource_dir
   /GenericResourcePathSep
         .file_name_separator readonly .forcedef         % pssys'params 
is r-o
   (%diskFontResourceDir) cvn (/Resource/Font/) readonly .forcedef 
  % pssys'params is r-o
   (%diskGenericResourceDir) cvn (/Resource/) readonly .forcedef % 
pssys'params is r-o
end
end

Note the .file_name_directory_separator in the first section and 
..file_name_separator in the second section.  Those are backwards.  It 
needs to .file_name_separator in the first section and 
..file_name_directory_separator in the second section.

Now look at this code:

% Define the system parameters used for the Generic implementation of
% ResourceFileName.
systemdict begin

%     - .default_resource_dir <string>
/.default_resource_dir {
   /LIBPATH .systemvar {
     dup .file_name_current eq {
       pop
     } {
       (Resource) search {
         exch concatstrings
         exch pop
         .file_name_directory_separator concatstrings exit
       } {
         pop
       } ifelse
     } ifelse
   } forall
} bind def

This code is searching the string LIBPATH (which is GS_LIB on VMS) for 
the string "Resource".  Since "GS_LIB" doesn't contain "Resource", the 
resource directory tree is never found and no resources can be loaded. 
The fix here was to add code to translate the GS_LIB logical name, find 
the element that specifies the resource directory, then add both the 
[Resource] and [Resource.Init] paths to LIBPATH.  For example:

My GS_LIB is defined as follows:

$ show log gs_lib
    "GS_LIB" = "$1$DGA1:[UTILITIES.GS.LIB]" (LNM$SYSTEM_TABLE)
         = "$1$DGA1:[UTILITIES.GS.FONTS]"
         = "$1$DGA1:[UTILITIES.GS.Resource]"
(note that the case of "Resource" must match what gs_res.ps is looking 
for but only in the logical name - it need not match on disk).

After processing, the search path that Ghostscript uses becomes:

$1$DGA1:[UTILITIES.GS.Resource], $1$DGA1:[UTILITIES.GS.Resource.Init], 
GS_LIB

The final part of the fix was to add some code to gp_vms.c to properly 
combine the type of filespecs gs_res.ps was now presenting.  This solved 
everything except finding icc profiles.  Ghostscript has a little item 
hard-coded into it as follows:

define DEFAULT_DIR_ICC   "%rom%iccprofiles/"

The code that looks for icc profiles does not look anywhere except in 
the %rom device.  It does not call the code that searches LIBPATH.  The 
only straightforward fix here (beyond making a lot of code changes to 
the ICC manager) is to simply make sure there is a %rom device.

So, after all of the changes, here is the output of gs -h:
GPL Ghostscript 9.05 (2012-02-08)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
  -dNOPAUSE           no pause after page   | -q       `quiet', fewer 
messages
  -g<width>x<height>  page size in pixels   | -r<res>  pixels/inch 
resolution
  -sDEVICE=<devname>  select device         | -dBATCH  exit after last file
  -sOutputFile=<file> select output file: - for stdout, |command for pipe,
                                          embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 
PostScriptLevel3 PDF
Default output device: x11alpha
Available devices:
    alc1900 alc2000 alc4000 alc4100 alc8500 alc8600 alc9100 bbox bit bitcmyk
    bitrgb bj10e bj200 bjc600 bjc800 bjc880j bjccmyk bjccolor bjcgray 
bjcmono
    bmp16 bmp16m bmp256 bmp32b bmpgray bmpmono bmpsep1 bmpsep8 cdeskjet
    cdj1600 cdj550 cdj670 cdj850 cdj880 cdj890 cdj970 cdjcolor cdjmono
    cdnj500 chp2200 cljet5 cljet5c deskjet devicen djet500 dl2100 epl2050
    epl2050p epl2120 epl2500 epl2750 epl5800 epl5900 epl6100 epl6200 
eplcolor
    eplmono eps9high eps9mid epson epsonc epswrite faxg3 faxg32d faxg4 gdi
    hl1240 hl1250 hpdj1120c hpdj310 hpdj320 hpdj340 hpdj400 hpdj500 hpdj500c
    hpdj510 hpdj520 hpdj540 hpdj550c hpdj560c hpdj600 hpdj660c hpdj670c
    hpdj680c hpdj690c hpdj850c hpdj855c hpdj870c hpdj890c hpdjplus
    hpdjportable ibmpro inkcov jpeg jpegcmyk jpeggray la50 la70 la75 
la75plus
    laserjet lex2050 lex3200 lex5700 lex7000 lips2p lips4 lips4v lj5gray
    lj5mono ljet2p ljet3 ljet3d ljet4 ljet4d ljetplus ln03 lp1800 lp1900
    lp2200 lp2400 lp2500 lp3000c lp7500 lp7700 lp7900 lp8000c lp8100 lp8200c
    lp8300c lp8300f lp8400f lp8500c lp8600 lp8600f lp8700 lp8800c lp8900
    lp9000b lp9000c lp9100 lp9200b lp9200c lp9300 lp9400 lp9500c lp9600
    lp9600s lp9800c lps4500 lps6500 lxm3200 md2k md5k nullpage oki4w omni
    oprp opvp pamcmyk32 pamcmyk4 pbm pbmraw pcl3 pcx16 pcx24b pcx256 pcxcmyk
    pcxgray pcxmono pdfwrite pgm pgmraw pgnm pgnmraw pj pjxl pjxl300 pkm
    pkmraw pksm pksmraw png16 png16m png256 pngalpha pnggray pngmono 
pngmonod
    pnm pnmraw ppm ppmraw ps2write psdcmyk psdrgb psgray psmono psrgb 
pswrite
    pxlcolor pxlmono samsunggdi spotcmyk stcolor tiff12nc tiff24nc tiff32nc
    tiff48nc tiff64nc tiffcrle tiffg3 tiffg32d tiffg4 tiffgray tifflzw
    tiffpack tiffscaled tiffscaled24 tiffscaled8 tiffsep tiffsep1 txtwrite
    uniprint x11 x11alpha x11cmyk x11gray2 x11gray4 x11mono xcf xes
Search path:
    %rom%[Resource.Init] , %rom%[lib] , GS_LIB
Initialization files are compiled into the executable.
For more information, see GS_DOC:Use.htm.
Please report bugs to bugs.ghostscript.com.

And here is the output of the command that started it all:

GS> (*) {==} 99 string /CMap resourceforall
(Adobe-GB1-5)
(GBK-EUC-H)
(UniJIS-UCS2-V)
(Adobe-Korea1-0)
(KSCms-UHC-H)
(GBK2K-H)
(90msp-RKSJ-V)
(UniJIS2004-UTF16-H)
(78-H)
(HKm314-B5-V)
(V)
(NWP-V)
(GBTpc-EUC-H)
(B5pc-V)
(UniJIS-UCS2-H)
(GBK2K-V)
(Katakana)
(KSCms-UHC-V)
(KSC-EUC-V)
(UniJISX0213-UTF32-V)
(EUC-H)
(Adobe-Japan1-4)
(UniJIS-UTF8-V)
(UniCNS-UTF32-V)
(GBT-V)
(HKm314-B5-H)
(KSCms-UHC-HW-V)
(NWP-H)
(HKscs-B5-H)
(UniJISPro-UTF8-V)
(HKscs-B5-V)
(Adobe-GB1-2)
(KSC-EUC-H)
(UniJISX0213-UTF32-H)
(GB-V)
(UniKS-UTF8-V)
(UniJIS-UTF8-H)
(Add-V)
(78-EUC-V)
(GBT-H)
(HKgccs-B5-V)
(CNS2-V)
(Adobe-Japan1-5)
(UniCNS-UCS2-V)
(Ext-RKSJ-V)
(90ms-RKSJ-V)
(KSC-Johab-H)
(Adobe-GB1-1)
(83pv-RKSJ-H)
(Identity-UTF16-H)
(GB-H)
(ETHK-B5-V)
(UniKS-UTF8-H)
(UniJIS-UTF32-V)
(GBT-EUC-V)
(H)
(Adobe-CNS1-2)
(78-EUC-H)
(Adobe-Japan1-2)
(UniGB-UTF16-V)
(UniCNS-UCS2-H)
(Add-RKSJ-H)
(Adobe-CNS1-4)
(90ms-RKSJ-H)
(78-RKSJ-V)
(KSC-Johab-V)
(Adobe-GB1-0)
(Adobe-Korea1-1)
(ETHK-B5-H)
(UniKS-UTF32-V)
(UniJIS-UTF32-H)
(UniCNS-UTF8-V)
(UniGB-UTF16-H)
(UniJISPro-UCS2-HW-V)
(UniCNS-UTF32-H)
(UniCNS-UTF16-V)
(HKdlb-B5-H)
(GBT-EUC-H)
(CNS2-H)
(Add-RKSJ-V)
(Add-H)
(Adobe-CNS1-3)
(78ms-RKSJ-V)
(Adobe-CNS1-6)
(Identity-V)
(GBKp-EUC-V)
(UniGB-UTF8-V)
(UniKS-UTF32-H)
(UniJIS-UTF16-V)
(HKdla-B5-V)
(78-RKSJ-H)
(Adobe-Japan1-1)
(ETen-B5-V)
(CNS1-V)
(UniCNS-UTF8-H)
(Adobe-CNS1-5)
(Hiragana)
(Identity-H)
(UniGB-UTF8-H)
(UniKS-UTF16-V)
(UniJIS2004-UTF8-V)
(B5pc-H)
(78ms-RKSJ-H)
(ETen-B5-H)
(Hankaku)
(CNS1-H)
(UniGB-UCS2-V)
(UniHojo-UCS2-H)
(RKSJ-V)
(GBpc-EUC-V)
(UniKS-UTF16-H)
(UniJIS-UTF16-H)
(EUC-V)
(KSC-H)
(UniJIS2004-UTF8-H)
(HKgccs-B5-H)
(KSCpc-EUC-V)
(B5-V)
(GBTpc-EUC-V)
(Ext-RKSJ-H)
(UniGB-UCS2-H)
(CNS-EUC-V)
(Adobe-CNS1-0)
(ETenms-B5-V)
(UniKS-UCS2-V)
(90msp-RKSJ-H)
(Adobe-CNS1-1)
(UniGB-UTF32-V)
(UniJISX02132004-UTF32-V)
(UniJIS-UCS2-HW-V)
(UniJIS2004-UTF32-V)
(HKdlb-B5-V)
(KSCms-UHC-HW-H)
(Adobe-Japan1-0)
(90pv-RKSJ-V)
(78-V)
(ETenms-B5-H)
(UniKS-UCS2-H)
(GB-EUC-H)
(Adobe-GB1-4)
(HKdla-B5-H)
(UniJISX02132004-UTF32-H)
(UniJIS-UCS2-HW-H)
(UniCNS-UTF16-H)
(UniJIS2004-UTF32-H)
(Roman)
(HKm471-B5-V)
(B5-H)
(RKSJ-H)
(Ext-H)
(WP-Symbol)
(GBK-EUC-V)
(UniJISPro-UCS2-V)
(GBKp-EUC-H)
(CNS-EUC-H)
(Adobe-Japan1-6)
(KSCpc-EUC-H)
(Ext-V)
(Adobe-Japan1-3)
(UniGB-UTF32-H)
(GBpc-EUC-H)
(Adobe-GB1-3)
(90pv-RKSJ-H)
(GB-EUC-V)
(UniJIS2004-UTF16-V)
(KSC-V)
(Adobe-Korea1-2)
(HKm471-B5-H)
GS>

Thanks very much for all your comments.  I think we have a better 
product on VMS now.

The only question I have left is how do I get these changes to the 
ghostscript developers?

Mark Berryman

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

"Mark Berryman" <mark@theberrymans.com> wrote in message news:jthntf
$1ob8$1@adenine.netfront.net...
> ...
> There are two errors in gs_res.ps, one of which has already been noted.
>  Here is the original code (which will probably wrap):
> ...
>      dup () ne {
>      .file_name_directory_separator concatstrings
>     } if
> ...
>   /GenericResourcePathSep
>         .file_name_separator readonly .forcedef         % pssys'params
> ...
>
> Note the .file_name_directory_separator in the first section and
> .file_name_separator in the second section.  Those are backwards.  It
> needs to .file_name_separator in the first section and
> .file_name_directory_separator in the second section.

This I agree with:
      dup () ne {
-     .file_name_directory_separator concatstrings
+     .file_name_separator concatstrings
    } if


but I don't agree with:

    /GenericResourcePathSep
-         .file_name_separator readonly .forcedef         %
pssys'params
+         .file_name_directory_separator readonly .forcedef         %
pssys'params

The "PostScript Reference Manual" 3rd edition <http://www.adobe.com/
devnet/postscript.html> section C.3.6 "Resource File Location" (PDF
page 773) tells what GenericResourcePathSep is for. It goes between
the category name and the resource name. Since the category is
materialized by a directory (the last one in the path) and the
resource by a file, the separator should be "]" on OpenVMS, not ".".

> ...
> /.default_resource_dir {
>   /LIBPATH .systemvar {
> ...
>   } forall
> } bind def
>
> This code is searching the string LIBPATH (which is GS_LIB on VMS) for
> the string "Resource".  Since "GS_LIB" doesn't contain "Resource", the
> resource directory tree is never found and no resources can be loaded.
> ... ...
> Search path:
>    %rom%[Resource.Init] , %rom%[lib] , GS_LIB

The placement of the text "GS_LIB" shows it comes from the
GS_LIB_DEFAULT, the value of the GS_LIB "environment
variable" (fetched at runtime), if any, is listed before the %rom%
paths.

GS_LIB_DEFAULT is set at build time, in the makefiles, and is expected
to be a path or a list of paths that can be combined with filenames/
etc. The standard "openvms.mak" defines it as such, but "openvms.mmk"
does not. Or should this be set to "GS_LIB:[" and not just "GS_LIB"?
(Please pardon my OpenVMS-ignorance if this is a stupid question.)

> ...
> The final part of the fix was to add some code to gp_vms.c to properly
> combine the type of filespecs gs_res.ps was now presenting.

OK. (But this depends a lot on the solutions adopted for other
problems.)

> ...
> Ghostscript has a little item hard-coded into it as follows:
>
> define DEFAULT_DIR_ICC   "%rom%iccprofiles/"
>
> The code that looks for icc profiles does not look anywhere except in
> the %rom device.

This cannot be true. I haven't found the exact code that does this,
but I can tell for sure that if building (tested on Windows) with
COMPILE_INITS=0 it looks for the default ICC profiles on disk (and
fails to start if not found there).

> ...
> The only question I have left is how do I get these changes to the
> ghostscript developers?

Ghostscript Bugzilla:
<http://bugs.ghostscript.com/>

the gs-devel mailing list:
<http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel>

or, if you need to contact developers in a more "realtime" way:
#ghostscript IRC channel on freenode.net.
Note this channel is logged <http://ghostscript.com/irclogs/>, so is
the devs are not on-line (matter of timezone) you can still type your
questions and chances are you will get responses later.

(You don't need to keep this message for the above links, you find
them on GS's homepage <http://www.ghostscript.com/>.)

sags

On 7/11/12 4:11 AM, SaGS wrote:
> "Mark Berryman" <mark@theberrymans.com> wrote in message news:jthntf
> $1ob8$1@adenine.netfront.net...
>> ...
>> There are two errors in gs_res.ps, one of which has already been noted.
>>   Here is the original code (which will probably wrap):
>> ...
>>       dup () ne {
>>       .file_name_directory_separator concatstrings
>>      } if
>> ...
>>    /GenericResourcePathSep
>>          .file_name_separator readonly .forcedef         % pssys'params
>> ...
>>
>> Note the .file_name_directory_separator in the first section and
>> .file_name_separator in the second section.  Those are backwards.  It
>> needs to .file_name_separator in the first section and
>> .file_name_directory_separator in the second section.
>
> This I agree with:
>        dup () ne {
> -     .file_name_directory_separator concatstrings
> +     .file_name_separator concatstrings
>      } if
>
>
> but I don't agree with:
>
>      /GenericResourcePathSep
> -         .file_name_separator readonly .forcedef         %
> pssys'params
> +         .file_name_directory_separator readonly .forcedef         %
> pssys'params
>
> The "PostScript Reference Manual" 3rd edition <http://www.adobe.com/
> devnet/postscript.html> section C.3.6 "Resource File Location" (PDF
> page 773) tells what GenericResourcePathSep is for. It goes between
> the category name and the resource name. Since the category is
> materialized by a directory (the last one in the path) and the
> resource by a file, the separator should be "]" on OpenVMS, not ".".

I should have posted a diff instead of posting the code.  I made a cut 
and paste error.  This is the changed area of code:

%     - .default_resource_dir <string>
/.default_resource_dir {
   /LIBPATH .systemvar {
     dup .file_name_current eq {
       pop
     } {
       (Resource) search {
         exch concatstrings
         exch pop
         .file_name_directory_separator concatstrings exit
       } {
         pop
       } ifelse
     } ifelse
   } forall
} bind def

%  <path> <name> <string> .resource_dir_name <path> <name> <string>
/.resource_dir_name
{  systemdict 2 index .knownget {
      exch pop
      systemdict 1 index undef
    } {
      dup () ne {
      .file_name_separator concatstrings
     } if
     2 index exch //false .file_name_combine not {
       (Error: .default_resource_dir returned ) print exch print ( that 
can't combine with ) print =
       /.default_resource_dir cvx /configurationerror signalerror
     } if
   } ifelse
} bind def

>
>> ...
>> /.default_resource_dir {
>>    /LIBPATH .systemvar {
>> ...
>>    } forall
>> } bind def
>>
>> This code is searching the string LIBPATH (which is GS_LIB on VMS) for
>> the string "Resource".  Since "GS_LIB" doesn't contain "Resource", the
>> resource directory tree is never found and no resources can be loaded.
>> ... ...
>> Search path:
>>     %rom%[Resource.Init] , %rom%[lib] , GS_LIB
>
> The placement of the text "GS_LIB" shows it comes from the
> GS_LIB_DEFAULT, the value of the GS_LIB "environment
> variable" (fetched at runtime), if any, is listed before the %rom%
> paths.
>
> GS_LIB_DEFAULT is set at build time, in the makefiles, and is expected
> to be a path or a list of paths that can be combined with filenames/
> etc. The standard "openvms.mak" defines it as such, but "openvms.mmk"
> does not. Or should this be set to "GS_LIB:[" and not just "GS_LIB"?
> (Please pardon my OpenVMS-ignorance if this is a stupid question.)

GS_LIB *is* a path that can be combined with filenames.  It is, in fact, 
a list of paths.  Is just that the list of paths is handled behind the 
scenes by VMS and is invisible to the program.

On Unix and Windows, Ghostscript has to be provided a large list of 
directories to search in order for find everything.  Here is a typical 
example:

Search path:
    %rom%Resource/Init/ : %rom%lib/ :
    /usr/local/share/ghostscript/9.05/Resource/Init :
    /usr/local/share/ghostscript/9.05/lib :
    /usr/local/share/ghostscript/9.05/Resource/Font :
    /usr/local/share/ghostscript/fonts :
    /usr/local/share/fonts/default/ghostscript :
    /usr/local/share/fonts/default/Type1 :
    /usr/local/share/fonts/default/TrueType : /usr/lib/DPS/outline/base :
    /usr/openwin/lib/X11/fonts/Type1 : /usr/openwin/lib/X11/fonts/TrueType :
    /usr/share/cups/fonts

On Unix and Windows, if GS_LIB is defined as an environment variable, it 
goes into the search path before the %rom devices.  This is not true on 
VMS.  In fact, there is an explicit exception for VMS in this regard in 
the code.  This is because VMS has something called a logical name 
which, itself, can expand into a search list.  GS_LIB is a logical name. 
  To be consistent with how VMS works, it should not be necessary to 
hard-code a search path into the code and, with the changes made, it no 
longer is.

GS_LIB is typically defined as something like the following:

    "GS_LIB" = "$1$DGA1:[UTILITIES.GS.LIB]"
         = "$1$DGA1:[UTILITIES.GS.FONTS]"
         = "$1$DGA1:[UTILITIES.GS.Resource]"

Files are then found by using the syntax: GS_LIB:filename.ext and VMS 
will automatically search all of the directories listed in the GS_LIB 
logical name trying to find the file.  The program need have no 
knowledge that a search list is involved.  Ghostscript is an exception 
in that it needs to have explicit knowledge of both where the top of the 
Resource directory tree is and where [Resource.Init] is.  Now it does, 
not matter how GS_LIB is defined.

(No, defining GS_LIB_DEFAULT as GS_LIB:[ would not have helped in any 
way.  It would simply have broken everything.)

Note that openvms.mak is rarely used to build ghostscript because 
relatively few VMS systems have a make program that can read it.  It 
would probably be better if the developers could maintain openvms.mmk 
instead of openvms.mak.

>
>> ...
>> The final part of the fix was to add some code to gp_vms.c to properly
>> combine the type of filespecs gs_res.ps was now presenting.
>
> OK. (But this depends a lot on the solutions adopted for other
> problems.)
>
>> ...
>> Ghostscript has a little item hard-coded into it as follows:
>>
>> define DEFAULT_DIR_ICC   "%rom%iccprofiles/"
>>
>> The code that looks for icc profiles does not look anywhere except in
>> the %rom device.
>
> This cannot be true. I haven't found the exact code that does this,
> but I can tell for sure that if building (tested on Windows) with
> COMPILE_INITS=0 it looks for the default ICC profiles on disk (and
> fails to start if not found there).

The program name you want is gsicc_manage.c and the routine name is 
gsicc_open_search.  That routine accepts, among other things, a file 
name and a directory name (which may be null).  The only directory name 
any of the callers of this routine pass is the contents of 
gs_lib_ctx->profiledir.  This code then tries to open, in order: dir + 
filename, filename alone, %rom + filename.

As I stepped through the code with the debugger, gs_lib_ctx->profiledir 
was set to the value of DEFAULT_DIR_ICC and no other (by the routine 
gs_lib_ctx_init in gslibctx.c).

On your windows build, try adding a debugging print statement to the 
gsicc_open_search routine to see what directory names are being passed 
to it.  All I ever got was the value of DEFAULT_DIR_ICC.

[remainder deleted]

Mark Berryman

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

"Mark Berryman" <mark@theberrymans.com> wrote in message news:jtk60u
$10kn$1@adenine.netfront.net...
> ...
> GS_LIB *is* a path that can be combined with filenames.  It is, in fact,
> a list of paths.  Is just that the list of paths is handled behind the
> scenes by VMS and is invisible to the program.

Yes, that's one of the problems. It "is a path" from the host OS'es
point of view, but not good enough for Ghostscript's platform-
independent code. I understand you now solved this somehow, so OK.

> ...
> On Unix and Windows, Ghostscript has to be provided a large list of
> directories to search in order for find everything.  Here is a typical
> example:
>
> Search path:
>    %rom%Resource/Init/ : %rom%lib/ :
>    /usr/local/share/ghostscript/9.05/Resource/Init :
>    /usr/local/share/ghostscript/9.05/lib :
>    /usr/local/share/ghostscript/9.05/Resource/Font :
>    /usr/local/share/ghostscript/fonts :
>    /usr/local/share/fonts/default/ghostscript :
>    /usr/local/share/fonts/default/Type1 :
>    /usr/local/share/fonts/default/TrueType : /usr/lib/DPS/outline/base :
>    /usr/openwin/lib/X11/fonts/Type1 : /usr/openwin/lib/X11/fonts/TrueType :
>    /usr/share/cups/fonts

OK. This is GS_LIB_DEFAULT. You don't have any GS_LIB here.

> On Unix and Windows, if GS_LIB is defined as an environment variable, it
> goes into the search path before the %rom devices.

That's an important difference between GS_LIB and GS_LIB_DEFAULT.
While GS_LIB_DEFAULT is built into the executable, in order to allow
it to run on an "empty" system, GS_LIB is meant to be a user setting
that allows overriding anything on a computer-by-computer basis.

> This is not true on VMS.  In fact, there is an explicit exception
> for VMS in this regard in the code.

If I understand this correctly, on VMS "GS_LIB_DEFAULT equals GS_LIB".
This a very different behavior than for other platforms, and I don't
find it quite OK because this means:

(a) GS won't start unless the host is configured (GS_LIB defined)
(b) The user can never override the %rom%. S/he can change GS_LIB,
    but that turns out to have lower priority than the %rom% and
    there's nothing else (with higher priority) to configure.

In fact, I'm not completely satisfied with how GS_LIB_DEFAULT works on
Windows either. The trouble is the exact path(s) cannot be always
known at build time, for example if the exe will run from a USB mem
drive, which gets varying drive letters when mounted. I wrote a patch
to solve this <http://bugs.ghostscript.com/show_bug.cgi?id=689040#c2>,
but it did not find its way into the codebase; maybe it's possible to
implement gp_getenv_gslibrtdef() for OpenVMS similar to what I did for
Windows.

And an example why the above priority matters:

With the current arrangement on OpenVMS I don't see (unless using a
commandline switch) how to override the file cidfmap. There is an
empty one in %rom% and GS loads only the 1st it finds. So putting one
in a directory from OpenVMS's GS_LIB logical name (= other platform's
GS_LIB_DEFAULT) won't help. (I have a patch for this too, but it
didn't go into the codebase either <http://bugs.ghostscript.com/
show_bug.cgi?id=690146#c6>.)

> ...
>>> The code that looks for icc profiles does not look anywhere except in
>>> the %rom device.
>>
>> This cannot be true. I haven't found the exact code that does this,
>> but I can tell for sure that if building (tested on Windows) with
>> COMPILE_INITS=0 it looks for the default ICC profiles on disk (and
>> fails to start if not found there).
> ...

Now I found that piece of code.

There exists a system parameter named ICCProfilesDir that holds this
directory. gs_lev2.ps takes care to set it (look for "% Search for
valid (iccprofiles) directory as a sibling to (Resource)"), unless
already set somewhere else. That PostScript code fragment calls
gsicc_manage.c::gs_seticcdirectory() via
zusparam.c::set_icc_directory(). Maybe (not tested) with
COMPILE_INITS=1 this parameter is set to %rom% very early during the
initialisation and gs_lev2.ps does not set it again.

sags

On 7/12/12 2:28 AM, SaGS wrote:
> "Mark Berryman" <mark@theberrymans.com> wrote in message news:jtk60u
> $10kn$1@adenine.netfront.net...
>> ...
>> GS_LIB *is* a path that can be combined with filenames.  It is, in fact,
>> a list of paths.  Is just that the list of paths is handled behind the
>> scenes by VMS and is invisible to the program.
>
> Yes, that's one of the problems. It "is a path" from the host OS'es
> point of view, but not good enough for Ghostscript's platform-
> independent code. I understand you now solved this somehow, so OK.
>
>> ...
>> On Unix and Windows, Ghostscript has to be provided a large list of
>> directories to search in order for find everything.  Here is a typical
>> example:
>>
>> Search path:
>>     %rom%Resource/Init/ : %rom%lib/ :
>>     /usr/local/share/ghostscript/9.05/Resource/Init :
>>     /usr/local/share/ghostscript/9.05/lib :
>>     /usr/local/share/ghostscript/9.05/Resource/Font :
>>     /usr/local/share/ghostscript/fonts :
>>     /usr/local/share/fonts/default/ghostscript :
>>     /usr/local/share/fonts/default/Type1 :
>>     /usr/local/share/fonts/default/TrueType : /usr/lib/DPS/outline/base :
>>     /usr/openwin/lib/X11/fonts/Type1 : /usr/openwin/lib/X11/fonts/TrueType :
>>     /usr/share/cups/fonts
>
> OK. This is GS_LIB_DEFAULT. You don't have any GS_LIB here.
>
>> On Unix and Windows, if GS_LIB is defined as an environment variable, it
>> goes into the search path before the %rom devices.
>
> That's an important difference between GS_LIB and GS_LIB_DEFAULT.
> While GS_LIB_DEFAULT is built into the executable, in order to allow
> it to run on an "empty" system, GS_LIB is meant to be a user setting
> that allows overriding anything on a computer-by-computer basis.
>
>> This is not true on VMS.  In fact, there is an explicit exception
>> for VMS in this regard in the code.
>
> If I understand this correctly, on VMS "GS_LIB_DEFAULT equals GS_LIB".
> This a very different behavior than for other platforms, and I don't
> find it quite OK because this means:
>
> (a) GS won't start unless the host is configured (GS_LIB defined)
> (b) The user can never override the %rom%. S/he can change GS_LIB,
>      but that turns out to have lower priority than the %rom% and
>      there's nothing else (with higher priority) to configure.
>
> In fact, I'm not completely satisfied with how GS_LIB_DEFAULT works on
> Windows either. The trouble is the exact path(s) cannot be always
> known at build time, for example if the exe will run from a USB mem
> drive, which gets varying drive letters when mounted. I wrote a patch
> to solve this <http://bugs.ghostscript.com/show_bug.cgi?id=689040#c2>,
> but it did not find its way into the codebase; maybe it's possible to
> implement gp_getenv_gslibrtdef() for OpenVMS similar to what I did for
> Windows.
>
> And an example why the above priority matters:
>
> With the current arrangement on OpenVMS I don't see (unless using a
> commandline switch) how to override the file cidfmap. There is an
> empty one in %rom% and GS loads only the 1st it finds. So putting one
> in a directory from OpenVMS's GS_LIB logical name (= other platform's
> GS_LIB_DEFAULT) won't help. (I have a patch for this too, but it
> didn't go into the codebase either <http://bugs.ghostscript.com/
> show_bug.cgi?id=690146#c6>.)
>
>> ...
>>>> The code that looks for icc profiles does not look anywhere except in
>>>> the %rom device.
>>>
>>> This cannot be true. I haven't found the exact code that does this,
>>> but I can tell for sure that if building (tested on Windows) with
>>> COMPILE_INITS=0 it looks for the default ICC profiles on disk (and
>>> fails to start if not found there).
>> ...
>
> Now I found that piece of code.
>
> There exists a system parameter named ICCProfilesDir that holds this
> directory. gs_lev2.ps takes care to set it (look for "% Search for
> valid (iccprofiles) directory as a sibling to (Resource)"), unless
> already set somewhere else. That PostScript code fragment calls
> gsicc_manage.c::gs_seticcdirectory() via
> zusparam.c::set_icc_directory(). Maybe (not tested) with
> COMPILE_INITS=1 this parameter is set to %rom% very early during the
> initialisation and gs_lev2.ps does not set it again.

The Ghostscript code hardcodes the %rom device as the location 
regardless of the setting of COMPILE_INITS.  In fact, when this part of 
the code is executed:

   % First see if the current value is valid so we don't have to guess
   mark .currentuserparams .dicttomark /ICCProfilesDir get

the value returned (on VMS) is %rom%[iccprofiles] and that is true 
regardless of the value of COMPILE_INITS.  This setting comes from 
DEFAULT_DIR_ICC.  The key is that this code:

     % Search for valid (iccprofiles) directory as a sibling to (Resource)
     % and set it as a default if found.
     LIBPATH {
       (Resource) search {
         exch pop exch pop (iccprofiles) concatstrings
         .file_name_separator concatstrings
         dup (default_gray.icc) concatstrings status {
           pop pop pop pop
           mark exch /ICCProfilesDir exch .dicttomark .setuserparams2
           exit
         } {
           pop
         } ifelse
       } {
         pop
       } ifelse
     } forall
   } ifelse      % if currentuserparams ICCProfilesDir
} ifelse      % ICCProfilesDir set in systemdict (command line option)

wants the iccprofiles directory to be a sibling of the resource 
directory (which I didn't have) which is why I never saw anything except 
the %rom path.  My on disk structure now contains the following 
directories and now everything works without any %rom device.

Directory $1$DGA1:[UTILITIES.GS]

FONTS.DIR;1         iccprofiles.DIR;1   LIB.DIR;1           Resource.DIR;1

Now, I can address the concerns you've raised, at least for VMS.  I can 
think of no reason the same process wouldn't work for any other platform.

Step 1.  Build everything into the ROM, which means adding the files 
usually found on disk in [.lib] and [.fonts].

Step 2. Eliminate the use of GS_LIB_DEFAULT.

Step 3. If GS_LIB is defined at runtime, add it in front of the %ROM 
paths, the same say Unix and Windows do.

This will allow the program to work without *any* additional supporting 
files but will still allow a user to override any of the files placed 
into the ROM device.

Mark Berryman

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

All of the updates to the VMS version of Ghostscript have been 
completed.  GS.EXE can now exist as a standalone image; it needs no 
supporting files to run.  All of its resources and all of its fonts are 
built into the image.  If you issue the gs -h command, the search path 
looks like this:

Search path:
    %rom%[Resource.Init] , %rom%[lib]

However, you can also override anything built into the image by properly 
defining the GS_LIB logical name.  If you want to use your own set of 
fonts, for example, simply define GS_LIB to a directory that contains 
Fontmap.VMS and that will be the fontmap used instead of the one built it.

If you want to completely override all resource files built into the 
image, then GS_LIB will look something like this:

    "GS_LIB" = "$1$DGA1:[Utilities.GS.Lib]"
         = "$1$DGA1:[Utilities.GS.Fonts]"
         = "$1$DGA1:[Utilities.GS.Resource]"

The [.Lib] and [.Fonts] directories will be single directories.  [.Lib] 
would contain the files normally found in [.lib] of the ghostscript 
distribution and [.Fonts] would contain, well, font files.

[.Resource] would be a directory tree containing the following directories:

CIDFont.DIR;1       CIDFSubst.DIR;1     CMap.DIR;1      ColorSpace.DIR;1
Decoding.DIR;1      Encoding.DIR;1      Font.DIR;1      Init.DIR;1
SubstCID.DIR;1

Finally, iccprofiles.DIR;1 would be found in the same parent directory 
as Resource.DIR;1 ($1$DGA1:[Utilities.GS] in this particular case).

(Note that ghostscript looks explicitly for "Resource" in the path when 
trying to find the directories within [.Resource] and when trying to 
find the iccprofiles directory so "Resource" is case-sensitive within 
the GS_LIB definition but nothing else is).

Running ghostscript now shows the following as the Search path:

Search path:
    $1$DGA1:[Utilities.GS.Lib] ,
    $1$DGA1:[Utilities.GS.Fonts] ,
    $1$DGA1:[Utilities.GS.Resource] ,
    $1$DGA1:[Utilities.GS.Resource.Init] ,
    %rom%[Resource.Init] , %rom%[lib]

(Note that [.Resource.Init] is built automatically when GS_LIB contains 
[.Resource] but it need not exist or contain anything if you are not 
trying to override any Init files).

I will post the complete, updated kit in a few days.  Any feedback on 
this approach is more than welcome.

Mark Berryman

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

In article <jtso2h$b09$1@adenine.netfront.net>, Mark Berryman
<mark@theberrymans.com> writes: 

> All of the updates to the VMS version of Ghostscript have been 
> completed.  GS.EXE can now exist as a standalone image; it needs no 
> supporting files to run.  All of its resources and all of its fonts are 
> built into the image.  

While this sounds practical, are there any disadvantages?

> (Note that ghostscript looks explicitly for "Resource" in the path when 
> trying to find the directories within [.Resource] and when trying to 
> find the iccprofiles directory so "Resource" is case-sensitive within 
> the GS_LIB definition but nothing else is).

Does this mean that it works only on ODS-5?

> I will post the complete, updated kit in a few days.  Any feedback on 
> this approach is more than welcome.

I'm definitely interested, but it might be late summer before I have 
time to do any tests.

Does this kit look to be relatively stable?

On 7/15/12 12:57 AM, Phillip Helbig---undress to reply wrote:
> In article <jtso2h$b09$1@adenine.netfront.net>, Mark Berryman
> <mark@theberrymans.com> writes:
>
>> All of the updates to the VMS version of Ghostscript have been
>> completed.  GS.EXE can now exist as a standalone image; it needs no
>> supporting files to run.  All of its resources and all of its fonts are
>> built into the image.
>
> While this sounds practical, are there any disadvantages?

If there are, I haven't come across any.

>
>> (Note that ghostscript looks explicitly for "Resource" in the path when
>> trying to find the directories within [.Resource] and when trying to
>> find the iccprofiles directory so "Resource" is case-sensitive within
>> the GS_LIB definition but nothing else is).
>
> Does this mean that it works only on ODS-5?

No.  When Ghostscript translates the logical name, what it looks for in 
the translation is case-sensitive.  It neither knows nor cares about how 
the directory is actually spelled on disk.  In other words, the 
equivalence value in the logical name is case-sensitive, the on-disk 
structure is not.

>
>> I will post the complete, updated kit in a few days.  Any feedback on
>> this approach is more than welcome.
>
> I'm definitely interested, but it might be late summer before I have
> time to do any tests.
>
> Does this kit look to be relatively stable?

It has been 100% stable for me.  I assume there will be some feedback if 
this does not hold true for others.

Mark Berryman



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---