ghostscript converting to pdf-a - icc file correct? -

i'm using ghostscript 9.19 on windows system. when run ghostscript batch file, creates pdf. when ghostscript scheduled program, creates pdf without content - there's 1 blank page. command line same in both cases (one long line, split below due formating):

gswin32c.exe  -sstdout=d:\my_data\gs_stdout.log           -dpdfa=1 -dbatch -dnopause -dnooutersave          -scolorconversionstrategy=/rgb          -soutputiccprofile=d:\my_ps_files\adobergb1998.icc          -sdevice=pdfwrite          -soutputfile=d:\my_data\my_hopeful_pdfa_pdfa.pdf          -dpdfacompatibilitypolicy=1 "d:\my_ps_files/pdfa_def.ps" "d:\my_data\my_hopeful_pdfa_pdfa.ps"          > d:\my_data\my_hopeful_pdfa_gs_out.log  

my_hopefule_pdfa_gs_out.log never gets created. gs_stdout.log created.

whether pdf gets created appears related whether or not *.icc file present in directory ghostscript runs.

i different output in stdout.log file.

when works get:

gpl ghostscript 9.19 (2016-03-23) copyright (c) 2016 artifex software, inc.  rights reserved. software comes no warranty: see file public details. error: /undefinedfilename in (>) operand stack:    false execution stack:    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push dictionary stack:    --dict:1201/1684(ro)(g)--   --dict:0/20(g)--   --dict:80/200(l)-- current allocation mode local last os error: invalid argument 

the error log when fails is:

gpl ghostscript 9.19 (2016-03-23) copyright (c) 2016 artifex software, inc.  rights reserved. software comes no warranty: see file public details. error: /undefinedfilename in --file-- operand stack:    --nostringval--   --nostringval--   (adobergb1998.icc)   (r) execution stack: %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1967   1   3   %oparray_pop   1966   1   3   %oparray_pop   1950   1   3   %oparray_pop   1836   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--       --nostringval--   2   %stopped_push   --nostringval-- dictionary stack:    --dict:1201/1684(ro)(g)--   --dict:0/20(g)--   --dict:79/200(l)-- current allocation mode local last os error: no such file or directory current file position 818 

can me interpreting output. adobergb1988.icc in both cases resides in d:\my_ps_files\adobergb1998.icc specified in command line.

the forward slash irrelevant, ghostscript can handle either type, or both in same path, here (though agree @ least sensible stick 1 or other).

the actual problem can't find file 'adobergb1998.icc' (in postscript undefinedfilename means interpreter cannot find file) , without seeing contents of pdfa_def.ps file impossible why (because file opened in pdfa_def.ps)

however plausible guess in 1 case executing ghostscript folder d:\my_ps_files, icc profile file in current directory, whereas in other case executing ghostscript 'some other' directory, file not in current directory. modified filename in there that's not default name, looks did not specify complete path.

the 'as specified in command line' refers different invocation, in case using adobergb1998.icc outputiccprofile, however, pdfa_def.ps needs use set destoutptuprofile in outputintent dictionary, different thing altogether , not specified on command line. because there no way create dictionary object on command line, has done in postscript, , since dictionary creation has done in postscript, creation of contents, , 1 of destoutputprofile, , since that's read file need specify in postscript too.

you should put full path specification icc profile in pdfa_def.ps instead of leaving implicitly current working directory.

note destoutputprofile , outputiccprofile different things, not need specify outputiccprofile high level output, that's control rendering, has no effect here , i'd drop it.

the reason error @ in batch file because '>' shell command, if put in batch file won't work, passed ghostscript command line argument. luckily happens after processing complete, has no ill effects. wouldn't have contained anyway, since you've redirected stdout file.

don't set -dnooutersave unless have reason, not folklore (there reason setting it, don't appear using in way). unless specific conditions apply, no more potentially slow down processing (for complex reasons related garbage collection).