When I run GhostScript 9.20 on Windows 10 on a file that consists of 1 false .outputpage 1 false .outputpage showpage I get one page of valid output followed by a crash with the error message GPL Ghostscript 9.20 (2016-09-26) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Unrecoverable error: unknownerror in .outputpage Operand stack: 1 false gsapi_execute_cont returns -1 Error updating TIFF header gsapi_exit returns 0 A second (but not third) tif file, corrupt gets created. I get similar results with 9.21 or jpeg instead of tif. Oddly, GhostView has no problem previewing files with this construct, but chokes when I try to convert.
Firstly, .outputpage is an undocumented Ghostscript-specific internal operator, you should not be using that at all. We reserve the right to change the behaviour of such internals at will and without notice. Having said that, I can't reproduce any problem either. Of course, the absence of a command line makes it difficult to reproduce what you are doing. Nevertheless, I tried the tiff24nc device (since your comment implied TIFF) and used both -sOutputFile=out%d.tif (again your comment implied the expectation of multiple otuput files) and -sOutputFile=out.tif. Both of these work without problem for me. You are going to have to provide a command line which reproduces the problem.
First, thank you Ken Sharp. On my Windows 10 machine, "C:\Program Files\gs\gs9.19\bin\GSWin32c" -sDEVICE=tiff24nc -r300 -sOutputFile="C:\Users\David\Desktop\outputpage%03d.TIF" -dNOPAUSE -dDEVICEWIDTHPOINTS=792 -dDEVICEHEIGHTPOINTS=792 "C:\Users\David\Desktop\outputpage.ps" -c quit results in GPL Ghostscript 9.19 (2016-03-23) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Error: /unknownerror in --.outputpage-- Operand stack: 1 false 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:1197/1684(ro)(G)-- --dict:0/20(G)-- --dict:78/200(L)-- Current allocation mode is local Current file position is 42 Let me know if I can further help my case. I have tried i t also on an Windows 8 machine, and with several different recent releases of GhostScript. So I'm finding the issue quite robust. Sadly, Adobe years ago deprecated copypage , and I don't know another way to get this functionality. When it works, I find it very usual, for example, in animation work.
(In reply to David Feldman from comment #2) > On my Windows 10 machine, > "C:\Program Files\gs\gs9.19\bin\GSWin32c" -sDEVICE=tiff24nc -r300 > -sOutputFile="C:\Users\David\Desktop\outputpage%03d.TIF" -dNOPAUSE > -dDEVICEWIDTHPOINTS=792 -dDEVICEHEIGHTPOINTS=792 > "C:\Users\David\Desktop\outputpage.ps" -c quit > > results in > > GPL Ghostscript 9.19 (2016-03-23) > Copyright (C) 2016 Artifex Software, Inc. All rights reserved. > This software comes with NO WARRANTY: see the file PUBLIC for details. > Error: /unknownerror in --.outputpage-- Using that command line I do indeed see the error. This is because, at that media size and with that resolution, the display list is used. It looks to me like the clist doesn't like multiple .outputpage operations without an initgraphics. I can't say I'm surprised, since its intended to accumulate marking operations until the end of the page. Internally we use .outputpage to implement showpage. I'll reassign this to Ray as a clist problem, but I suspect his response will be 'you can't do that'. As a work-around, if you increase the size of the page buffer sufficiently to hold the entire page in memory then the display list doesn't get used, and .outputpage will work as you expect. Adding -dMaxBitmap=300000000 to your command line worked for me. Of course if you use different media sizes or resolutions you will need to re-calculate > Let me know if I can further help my case. I have tried i t also on an > Windows 8 machine, and with several different recent releases of > GhostScript. So I'm finding the issue quite robust. So what version of Ghostscript were you previously using where this behaved as you expected ? > Sadly, Adobe years ago deprecated copypage , and I don't know another way > to get this functionality. When it works, I find it very usual, for > example, in animation work. I'm afraid that if you abuse operators for unintended purposes, you can't really be surprised if they don't work they way you want.
The clist_finish_page function does have a "flush" parameter that allows for appending to an existing clist, but we fail on the next call to clist_close_writer_and_init_reader when it tries to read the color_usage_array pseudo-band. This is because the clist_fread_chars cache filesize has not been updated after writing more characters, so the read (cl_cache_read) thinks the requested position is past the EOF. The cache slot needs to be invalidated when we write into a block that is in the cache. Fixing this by destroying the read cache when we write fixes the error, but the output is not correct since the cmd_opv_end_page written for the first .outputpage stops the reading. So, while the data has been written to the files, it never gets rendered to the page. I'll commit the fix for the cache problem, but leave the bug open and mark fixing the rest of it bountiable. Also the -sBandListStorage=memory needs fixing (it returns ioerror from the second .outputpage)
>So what version of Ghostscript were you previously using where this behaved as you expected ? Doubtless the command behaved as expected in a context where I was asking for lower resolution. I've been making art using PostScript for decades. I could, if you want me to look, find where and when this occurs in my old code, but I've never even thought to keep track specifically of the version numbers of the GhostScript packages I've use to render code, project by project. Thank you for the workaround!!!
The change to use the clist for large bitmaps on non-printer devices (such as the display device) was: commit 4e44c995bcc7a2aa6c32e23cb73fd532a93f5b1c Author: Ray Johnston <ray.johnston@artifex.com> Date: Tue Nov 26 11:15:17 2013 -0800 Fix bug 689805: Use a clist for pages with transparency that need lots of RAM This change uses -dMaxBitmap=___ to decide when to use clist mode. A large enough number will use page mode (not clist mode).
Ghostscript no longer exports internal operators for security reasons.