Bug 695860 - Regression (9.14->9.15): pdfwrite creates blank files
Summary: Regression (9.14->9.15): pdfwrite creates blank files
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: 9.15
Hardware: PC Linux
: P4 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-06 11:24 UTC by Marek Kubica
Modified: 2015-03-18 02:30 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
Reproducer (1.18 KB, application/postscript)
2015-03-06 11:24 UTC, Marek Kubica
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marek Kubica 2015-03-06 11:24:50 UTC
Created attachment 11501 [details]
Reproducer

Hi,

I used to write PostScript by hand and realized that during the update on Fedora from Ghostscipt 9.14 to 9.15, the pdfwrite device broke.

What I expected (and what happens in 9.14):

$ gs -sDEVICE=pdfwrite -sOutputFile=bug.pdf -dBATCH -dNOPAUSE bug.ps

Generates PDF with a logo as PDF. Black on white.

What actually happens (in 9.15):

$ gs -sDEVICE=pdfwrite -sOutputFile=bug.pdf -dBATCH -dNOPAUSE bug.ps

Generates blank PDF.

Interestingly enough, this happens in the pdfwrite device, when running

$ gs bug.ps

the logo gets displayed just fine. I didn't test other output devices.

I've reproduced it on Fedora 21, Arch Linux current and with the 9.15 upstream source. The 9.14 upstream source does not have this problem.

There's plenty of files that can reproduce the issue, I've attached a simple case, but my repository at https://github.com/Leonidas-from-XIV/tum-script contains lots more. If desired, I can also attach correct and incorrect PDFs.

regards,
Marek
Comment 1 Ken Sharp 2015-03-06 13:21:36 UTC
Your PDF file does not contain a 'showpage', which is why it doesn't draw anything.

The content of your PostScript file is present in the output PDF but is overwritten by a white rectangle caused by the initgraphics at the end of the page, caused by closing the devie when the interpreter exits.

Fundamentally you need to add a showpage to your PostScript files.
Comment 2 Marek Kubica 2015-03-06 13:26:51 UTC
Thanks for your quick answer.

I considered that my PostScript code was wrong but  it used to work for 6 years, worked in the X11 output and there was no note about incompatibility in the 9.15 release notes. So the old behaviour was wrong to start with?
Comment 3 Ken Sharp 2015-03-06 13:33:55 UTC
(In reply to Marek Kubica from comment #2)
> Thanks for your quick answer.
> 
> I considered that my PostScript code was wrong

 'wrong;' is not the case here. Its perfectly valid to have a PostScript program which makes no marks, nor contains a showpage. Its not 'wrong' to have such a program, but expectations of the behaviour may be wrong ;-)


> but  it used to work for 6
> years, worked in the X11 output and there was no note about incompatibility
> in the 9.15 release notes.

I wouldn't regard this as an incompatiblilty myself.


> So the old behaviour was wrong to start with?

I haven't (yet) concluded that there is or isn't a problem. I'm in a meeting for the next 2 days so I'm a little busy to investiage fully.

The fact that any device renders anything is, technically, incorrect according to the PLRM. Until a showpage occurs the raster should not be transferred to the device. However, people often want to render EPS files which are not permitted to contain a showpage.... So there are 'convenacks in Ghostscript which are technicallyience' h invalid but do what people want.

I suspect (I can't recall for sure at the moment) the action in 9.14 was raised as a bug and altered because of that bug report. The action at present appears to me at this moment to be correct, even if it is different to what went before, but that's true of any bug.
Comment 4 Ken Sharp 2015-03-08 13:49:40 UTC
OK this  in behaviour was introduced in commit d0816120fdae4e9592269d98e933cbdf99faad5e

The problem occurs because that code introduces a 'setpagedevice' in order to disable background printing before exiting the interpreter. This means that it alos occurs before we close the device. pdfwrite isn't psychic; because the job doesn't execute a showpage, it has to wait until the device is closed before it writes the accumulated marking operations to the page.

Unfortunately, setpagedevice executes an implicit erasepage, which means that the accumulated content is still present, but is then overwritten by the full page white rectangle which results from the erasepage.

My fix for this is to alter the code which disables background printing so that it only executes if background printing is turned on. In imain.c, around line 883, alter:

    if (minst->init_done >= 1) {
        gs_main_run_string(minst,
            "/systemdict .systemexec /begin .systemexec \
            <</BeginPage {pop} /EndPage {pop pop //false } \
              /BGPrint false /NumRenderingThreads 0>> setpagedevice \
              serverdict /.jobsavelevel get 0 eq {/quit} {/stop} ifelse end \
              .systemvar exec",
            0 , &exit_code, &error_object);
    }

To:

    if (minst->init_done >= 1) {
        gs_main_run_string(minst,
            "/systemdict .systemexec /begin .systemexec \
            currentpagedevice /BGPrint .knownget{ \
			{ \
            <</BeginPage {pop} /EndPage {pop pop //false } \
              /BGPrint false /NumRenderingThreads 0>> setpagedevice \
			  } if \
			  } if \
              serverdict /.jobsavelevel get 0 eq {/quit} {/stop} ifelse end \
              .systemvar exec",
            0 , &exit_code, &error_object);
    }

I'm reassigning this to Chris for review as he did the original change.
Comment 5 Chris Liddell (chrisl) 2015-03-18 02:30:48 UTC
Slightly tweaked version of Ken's solution committed:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3c4edb1e