The current language switch test files are limited to: tests_private/language_switch/testpage.pdf and tests/language_switch/tiger.eps Neither of which test the ability of the language switch build to switch languages.
Created attachment 6308 [details] multi-language job
The language switch build can switch languages on the command line as follows: pspcl6 [file ...] where file is any pcl, pclxl, pdf or postscript file. currently pcl and pclxl files can be appended in a single file with delimiting job control. This is broken for postscript. For starters the postscript interpreter is stripping pjl. Attached test.prn has tiger.pxl (a pxl job) followed by tiger.eps a ^D to terminate the postscript job followed by a owl (a pcl job). The first language switch is fine. The postscript interpreter continues to consume data past end of job and terminates with a syntax error scanning the pcl code. Assigning to Alex as there seem to be several front end issues with using the postscript and pdf interpreter in language switch mode.
This would need to be an option to the PS interp that language switch would use. I don't think we should change the behavior of Ghostscript when the option is not used. The section toward the end of gs_init.ps that defines <04> (depending on JOBSERVER) also defines ESC E <1b45> and has the UEL recognition and handling. When using the EXTERNAL_LANGUAGE_SWITCH (or whatever we call it) option, PostScript would need to execute 'quit' instead of just ignoring the job delimiter to exit to the autosense in the plmain loop. Note that since the <ESC> of the UEL has already been consumed, then Ghostscript would have to consume (read) the remainder of the UEL. Currently it only consumes the <ESC> and uses .peekstring to look ahead in the buffer, then relies on the '%-12345X' remainder to be treated as a comment. As an aside, treating the data after the UEL as a comment means that all data following up to a line terminator will also be treated as a comment by "regular" gs. The other issue is that the buffer passed to the PS interpreter must not be completely consumed since the data after job may be for a different PDL. Ordinarily, the ps interp expects to be run where it 'pulls' data from a source (usually stdin or a stdin callout), but in the 'push' run_string method used by ps_impl_process (in psi/psitop.c) there is no way to return an unused part of the string from run_string_continue. We would either have to come up with an alternate API method that _would_ indicate how much of the string was actually consumed, or pre-scan the input buffer for ALL of the potential delimiters, and only send that part of the buffer (including the delimiter) to run_string_continue, then check if the return code was e_Quit (meaning PS had executed the 'quit').
Apparently we have simple files now which do this, in the test repository.