Bug 855009 - documents fail to fully print because of stackunderflow [NEEDINFO]
documents fail to fully print because of stackunderflow
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: poppler (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-06 10:01 EDT by John Dennis
Modified: 2018-01-17 11:30 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 07:25:18 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jdennis: needinfo? (alex)
jdennis: needinfo? (mkasik)


Attachments (Terms of Use)
output of troubleshoot (418.21 KB, text/plain)
2012-09-06 11:13 EDT, John Dennis
no flags Details
PDF document which fails with stackunderflow (127.58 KB, application/pdf)
2013-06-10 11:19 EDT, John Dennis
no flags Details
CUPS job file (133.08 KB, text/plain)
2013-06-10 13:38 EDT, Michael Eager
no flags Details
Output from pdftops (which invokes pstops itself) (797.05 KB, application/octet-stream)
2013-06-11 07:00 EDT, Tim Waugh
no flags Details
Output from pdf2ps + pstops (462.95 KB, application/octet-stream)
2013-06-11 07:02 EDT, Tim Waugh
no flags Details
/etc/cups/ppd/MFC-9840CDW.ppd (26.24 KB, text/plain)
2013-06-12 14:34 EDT, John Dennis
no flags Details
failed.ps (797.08 KB, application/octet-stream)
2013-06-14 05:05 EDT, Tim Waugh
no flags Details
failed.ps with all PPD fragments deleted. (794.78 KB, application/postscript)
2013-06-14 12:14 EDT, Alex Cherepanov
no flags Details
this postscript files fails with stackunderflow (600.69 KB, text/plain)
2013-06-14 12:37 EDT, John Dennis
no flags Details
Correctly printing one pg (511.35 KB, application/postscript)
2013-06-14 13:36 EDT, Michael Eager
no flags Details
One page file which gets underflow (362.99 KB, application/postscript)
2013-06-14 13:42 EDT, Michael Eager
no flags Details
jrd-1.ps with the image removed. (341.09 KB, application/postscript)
2013-06-14 14:24 EDT, Alex Cherepanov
no flags Details
jrd-1-image.ps (22.15 KB, application/postscript)
2013-06-14 14:56 EDT, Alex Cherepanov
no flags Details
Change pop operations to cleartomark (22.28 KB, application/postscript)
2013-06-14 15:34 EDT, Alex Cherepanov
no flags Details
No assumptions about the stack. (22.19 KB, application/postscript)
2013-06-14 16:09 EDT, Alex Cherepanov
no flags Details
jrd-1-image4.ps (21.85 KB, application/postscript)
2013-06-14 16:34 EDT, Alex Cherepanov
no flags Details
jrd-1-image5.ps (22.40 KB, application/postscript)
2013-06-14 17:07 EDT, Alex Cherepanov
no flags Details
jrd-1-image6.ps (22.43 KB, application/postscript)
2013-06-15 08:23 EDT, Alex Cherepanov
no flags Details
jrd-1-image7.ps (22.49 KB, application/postscript)
2013-06-15 11:06 EDT, Alex Cherepanov
no flags Details

  None (edit)
Description John Dennis 2012-09-06 10:01:51 EDT
While printing on a Brother MFC-9840CDW multi-page documents frequently fail to print all their pages. This occurs when printing from Firefox but I believe I've seen the same thing when printing from PDF viewers as well.

Typically the first page or two prints fine (duplex mode is not a factor) then an error page prints and the document stops printing. The error page contains:

ERROR NAME;
    stackunderflow
COMMAND;
    pop
OPERAND STACK;

From seeing this error a number of times it would appear as if the page break is the culprit but that's only a uninformed supposition.

The printer has BR-Script3, I presume this is the printing language in use but I don't really know.
Comment 1 Jiri Popelka 2012-09-06 10:48:42 EDT
We need more info.
Output (after failing print job) from troubleshooter would be a good start.
https://fedoraproject.org/wiki/Printing/Debugging#Printing_troubleshooter
Comment 2 John Dennis 2012-09-06 11:13:24 EDT
Created attachment 610388 [details]
output of troubleshoot
Comment 3 Jiri Popelka 2012-09-06 11:34:51 EDT
Hmm, I can't find anything wrong in the log.

Do you see the same with other drivers, like:
Brother MFC9840CDW Foomatic/Postscript
Brother MFC9840CDW Foomatic/pxlcolor
'Generic Postscript Printer'
'Generic PCL 6/PCL XL Printer - CUPS+Gutenprint v5.2.x Simplified'
Comment 4 John Dennis 2012-09-06 12:28:32 EDT
Brother MFC9840CDW Foomatic/Postscript does not work at all, the printer just spits out page after page of mostly blank pages, some with jiberish.

Wouldn't the problem be in the generated print commands? Is there a way to capture that?
Comment 5 Andy Grover 2012-10-07 16:48:42 EDT
same issue on Brother MFC-9440CN.
Comment 6 Jiri Popelka 2012-10-08 07:28:41 EDT
AFAIK BR-Script3 is emulation for PostScript3 compatibility.

Printing test page using for example 'Brother MFC-9440CN' ppd shows the following in /var/log/cups/error_log:
[Job 178] envp[29]="FINAL_CONTENT_TYPE=application/vnd.cups-postscript"
[Job 178] Started filter /usr/lib/cups/filter/bannertops (PID 26854)
[Job 178] Started filter /usr/lib/cups/filter/pstops (PID 26855)
[Job 178] Started backend /usr/lib/cups/backend/... (PID 26856)

So the file sent to printer is a postscript generated with pstops filter.
If you want to see the content you need to run the pstops filter by hand [1] like:
PPD=/etc/cups/ppd/Brother-MFC-9440CN.ppd /usr/lib/cups/filter/pstops 1 me '' 1 '' <input.ps >pstops.ps
where input.ps is the file (in postscript) you want to print and pstops.ps is what's sent to printer.

[1] http://fedoraproject.org/wiki/How_to_debug_printing_problems#Running_filters_by_hand
Comment 7 Mark Nichols 2012-11-13 21:16:07 EST
Same printer (Brother MFC-9840CDW), same frustrating progression of problems for me.
Comment 8 Tim Waugh 2012-11-14 04:30:59 EST
Information is needed in order to make progress on fixing this bug.  See comment #6.
Comment 9 Matthew Saltzman 2013-04-24 13:30:41 EDT
I see this behavior on a Brother HL-5250_DN as well.
Comment 10 John Dennis 2013-06-07 15:30:26 EDT
I'm still having the same problems (now on F18). The most recent issue was printing a page in Firefox


http://docs.openstack.org/developer/keystone/middlewarearchitecture.html

I turned on cups debug and looked in the error log. I can see that it's received Content-Type of application/pdf and it runs the pdftops and then the pstops filter. I supposed the the most useful information to gather here is the pdf content so they can be fed into the filters.

How would I capture the pdf content that Firefox generates?

I also tried each of the Brother MFC-9840CDW drivers, BR-Script3 (the default), fails with stack underflow, Foomatic/Postcript fails with stack underflow, Foomatic/pxlcolor succeeds. FWIW I really want to use the BR-Script3 driver because it exposes the features of my printer.

I'm assuming the stack under flow is specific to postscript (of which BR-Script is a compatible variant or so I believe). Since postscript is stack based I'm guessing there is a problem in the filter where there isn't a matching number of pushes to pops. It's curious that this does not show up on other postscript printers because I assume the postscript filters are shared with all postscript printers. I wonder if the Brother implementation is less forgiving and aborts the job on a stack underflow and other implementations ignore the error.
Comment 11 Tim Waugh 2013-06-10 04:59:40 EDT
To capture the file that was given to CUPS, before any filtering, turn on job file preservation:

cupsctl PreserveJobFiles=yes

Job submissions will be stored in /var/spool/cups/d*
Comment 12 John Dennis 2013-06-10 11:19:45 EDT
Created attachment 759229 [details]
PDF document which fails with stackunderflow

Attached in the output of Firefox's PDF generator for the web page

http://docs.openstack.org/developer/keystone/middlewarearchitecture.html

Printing this results in the error stackunderflow.

From the debug log the file is passed to /usr/lib/cups/filter/pdftops filter and then I believe to pstops. I assume you do not need the output of these filters as they can regenerated easily, however if you would like me to attach the filter ouptut please let me know the correct way to invoke the filter (my attempt did not seem to work) and I will do so.
Comment 13 Michael Eager 2013-06-10 13:36:57 EDT
Also have the same error.  Can duplicate with web page mentioned in #10 and #12.
I updated LPR driver, CUPS wrapper, and PPD from Brother website, without change.

I've attached the saved job file.
Comment 14 Michael Eager 2013-06-10 13:38:15 EDT
Created attachment 759298 [details]
CUPS job file
Comment 15 Tim Waugh 2013-06-11 07:00:01 EDT
Created attachment 759560 [details]
Output from pdftops (which invokes pstops itself)

Here is the output after filtering through poppler's CUPS filter 'pdftops' like this:

PPD=BR9840_2_GPL.ppd /usr/lib/cups/filter/pdftops 1 tim '' 1 '' failed.pdf
Comment 16 Tim Waugh 2013-06-11 07:02:26 EDT
Created attachment 759561 [details]
Output from pdf2ps + pstops

Here is the output after filtering through ghostscript's 'pdf2ps' converter, and then CUPS's own pstops filter, like this:

pdf2ps failed.pdf
PPD=BR9840_2_GPL.ppd /usr/lib/cups/filter/pstops 1 tim '' 1 '' failed.ps
Comment 17 Tim Waugh 2013-06-11 07:04:51 EDT
Please try printing each of these files as raw jobs, like this:

lp -oraw -dmyqueue poppler.ps

The idea is to send them to the printer as-is without any additional filtering.

I expect the poppler.ps job to fail in the same manner as before, but would like to check.  I used the default settings in the PPD, and perhaps that makes a difference.

Let me know what happens with each.

Upstream bug report (from last year):
  https://bugs.linuxfoundation.org/show_bug.cgi?id=1083
Comment 18 John Dennis 2013-06-11 14:22:42 EDT
The poppler.ps file prints correctly.

The ghostscript.ps file prints a single blank page but does not produce any errors.

Since you were expecting the popple.ps file to fail but it didn't I wondered if it might be due to pdftops filter or the ppd on my system. So I generated a .ps file locally like this:

PPD=MFC-9840CDW.ppd /usr/lib/cups/filter/pdftops 1 jdennis '' 1 '' failed.pdf > jrd.ps

and then printed it like this:

lp -oraw -dMFC-9840CDW jrd.ps

and it also printed correctly.

I'm guessing this is not what is expected. Is it possible the printing pipeline adds something else along the way, job control commands for instance? Anyway, I'll defer to the expert. Let me know what other information you need.
Comment 19 Tim Waugh 2013-06-12 06:59:52 EDT
The PPD environment variable needs to point to the actual file.  I'd generated the PPD with its 'default' settings, and I expect your settings have been modified.

Try this:

PPD=/etc/cups/ppd/MFC-9840CDW.ppd /usr/lib/cups/filter/pdftops \
  1 jdennis '' 1 '' failed.pdf > jrd.ps
lp -oraw -dMFC-9840CDW.ppd jrd.ps

That should give the same result as 'lp -dMFC-9840CDW failed.pdf'.

Could you attach your /etc/cups/ppd/MFC-9840CDW.ppd file please?
Comment 20 John Dennis 2013-06-12 14:34:13 EDT
Created attachment 760297 [details]
/etc/cups/ppd/MFC-9840CDW.ppd

Running the pdftops filter in the manner you indicated and then sending it raw to the printer caused it to fail with the stack underflow error. Attached is the ppd file.
Comment 21 Tim Waugh 2013-06-13 12:10:56 EDT
So the two options that differ are:

             default    your setting

OptionTrays  2Trays     1Trays
Duplex       None       DuplexNoTumble

The OptionTrays setting shouldn't really make any difference to the output -- it is an installable option and its own purpose is to limit the available choices depending on what's installed.

That leaves the Duplex setting.  The default feature code for it is:

<</Duplex false /Tumble false>>setpagedevice

Your setting would make it:

<</Duplex true /Tumble false>>setpagedevice

(i.e. it just changes the 'false' to 'true' for /Duplex)

I wonder if this part of the prolog, from poppler, is tripping up:

/pdfSetup {
  /setpagedevice where {
    pop 2 dict begin
      /Policies 1 dict dup begin /PageSize 6 def end def
      { /Duplex true def } if
    currentdict end setpagedevice
  } {
    pop
  } ifelse
} def

I've been staring at it but can't see exactly what it's trying to do.

John, could you try changing the pdftops output from '/Duplex true' to '/Duplex false' and see if it prints out without errors?
Comment 22 John Dennis 2013-06-13 13:22:45 EDT
There were two places where "/Duplex true" appeared in jrd.ps

first I changed 

      { /Duplex false def } if                  

that still produced the error when sending the jrd.ps file to the printer in raw mode,

Then I also changed (so both were false)

<</Duplex false /Tumble false>>setpagedevice                                    

That also produced the error.

Did I correctly perform the test you wanted?

Then I changed the Duplex option in sys-config-printer to None and printed from Firefox, that also produced the same error.

Since I can't read Postfix I'm afraid I can't help you interpret the code block :-(
Comment 23 John Dennis 2013-06-13 13:36:30 EDT
Not sure if this helps, but here is a data point. I don't always get the stack underflow error, only sometimes. I would think if it's being caused by the ppd config duplex setting it would be consistent across all print jobs.

What I have noticed in the past is that stack underflow does seem to be related to the number of pages in the job. Sometimes I get the error after printing some pages, I believe, but I'm not 100% sure it's the first duplex page (i.e. starting on page 3) and sometimes I get it without having printed any pages successfully. I can't quite find a consistent pattern to it (maybe an even/odd number of pages?).

I don't understand how postscript handles pagination but I'm wondering if there is some outer loop that handles pages which is doing pushes and pops, could that loop get confused by the duplex setting?
Comment 24 Alex Cherepanov 2013-06-14 00:40:05 EDT
/pdfSetup procedure looks valid. It just sets policies and duplex depending
on the parameter. 

I'd be glad to look into this problem but I need a self-contained PS file that fails.
Comment 25 Tim Waugh 2013-06-14 05:05:48 EDT
Created attachment 761176 [details]
failed.ps

Here is a PostScript file generated by pdftops from MFC-9840CDW.ppd and failed.pdf with:

PPD=MFC-9840CDW.ppd /usr/lib/cups/filter/pdftops 1 tim '' 1 '' failed.pdf

I expect it to fail when printed to the device with 'lp -oraw' due to comment #20.

However, it works fine in ghostscript...
Comment 26 Alex Cherepanov 2013-06-14 12:14:19 EDT
Created attachment 761318 [details]
failed.ps with all PPD fragments deleted.

The file "failed.ps" also works on Distiller. There's no obvious problems
with PS fragments imported from the PPD.

The only way to proceed is to make experiments on the real printer.
For instance, delete fragments of the file until it works.

Attached is a sample file with all PPD fragments deleted. Does it work?
If so, you can delete fragments of code between %%BeginFeature and %%EndFeature
one by one to determine, which of them fails.
Comment 27 John Dennis 2013-06-14 12:37:57 EDT
Created attachment 761332 [details]
this postscript files fails with stackunderflow

I tried printing the failed.ps file attached in comment #25 using this command

lp -oraw -dMFC-9840CDW failed.ps

it printed successfully. Argh, so there is something different in the postscript files.

So using the same failed.pdf file attachment from comment #12 I generated the postscript file and printed like this:

PPD=/etc/cups/ppd/MFC-9840CDW.ppd /usr/lib/cups/filter/pdftops 1 jdennis '' 1 '' failed.pdf > jrd.ps
lp -oraw -dMFC-9840CDW jrd.ps

and it fails with the stackunderflow error.

I'm attaching the failing jrd.ps file so you can look at the differences between failed.ps (which worked) and the attached jrd.ps (which failed),

Hopefully the differences between the two .ps files will be meaningful and point in the direction of a solution.
Comment 28 Michael Eager 2013-06-14 13:36:12 EDT
Created attachment 761385 [details]
Correctly printing one pg

I edited the failed.ps file (which prints correctly) to only print the first page.
Comment 29 Michael Eager 2013-06-14 13:42:51 EDT
Created attachment 761387 [details]
One page file which gets underflow

This file is jrd.ps, edited to only print one page.  It also fails.

I notice that there are more differences between the printing file and the failing file.  The printing file has many more lines of text for ImData_12_0 and ImData_20_0.  I also notice that the failing file has two "pop" operation following the put for each of these, while the working file has only one.

I naively tried removing one of the pop operations, but that did not fix the problem.
Comment 30 Alex Cherepanov 2013-06-14 14:24:01 EDT
Created attachment 761396 [details]
jrd-1.ps with the image removed.

The files are quite different. Good one is level 2, bad one is level 3.
This affects image compression and font formats.

Please try the attached sample file that has no images.
Comment 31 Michael Eager 2013-06-14 14:32:02 EDT
New file prints OK.  This matches my observation: the files which fail all have images.
Comment 32 Alex Cherepanov 2013-06-14 14:56:35 EDT
Created attachment 761405 [details]
jrd-1-image.ps

Please try this file. It has just the image.
Comment 33 Michael Eager 2013-06-14 15:06:04 EDT
jrd-1-image.ps gets stackunderflow error.
Comment 34 Alex Cherepanov 2013-06-14 15:34:00 EDT
Created attachment 761418 [details]
Change pop operations to cleartomark

Please try this file. It should be more tolerant to broken interpreters.
Comment 35 John Dennis 2013-06-14 15:43:44 EDT
jrd-1-hack1.ps from comment #30 prints without error.

jrd-1-image.ps from comment #32 produces the stack underflow error.

I think we're finally converging on the issue!

I also noticed the difference between level 2 and level 3 when I looked at the ps files, but I wasn't sure what controlled given the PPD. In the printer settings I can only change the BR-Script level. Earlier I did an experiment changing the BR-Script level from 3 to 2 and regenerating the ps file using the modified PPD. What I noticed is the language level remained at 3 in the ps file but the BRScript in the ps file reflected the change. Chaning the BR-Script level had no effect on the printing results. It appears as though language-level and BR-Script level are two independent things. In my naive ignorance I assumed BR-Script is simply Brother's Postscipt emulation and changing BR-Script would also change the postscript language-level. Could this be the issue? The two language levels are disconnected when they shouldn't be? Other than the BR-Script level I could not find any other way to change the language level, it must be keyed off something else. And more to the point what language level should be used. I also noticed that when Tim generated his ps file, it worked but it was at level 2. So I don't understand why Tim is producing level 2 postscript but I'm producing level 3 postscript.
Comment 36 John Dennis 2013-06-14 15:47:24 EDT
sorry, jrd-1-image2.ps from comment #34 also fails with stack underflow
Comment 37 Alex Cherepanov 2013-06-14 16:09:35 EDT
Created attachment 761437 [details]
No assumptions about the stack.

Please try the attached file. It makes no assumptions about the stack
content during execution on the procedure data source.
Comment 38 John Dennis 2013-06-14 16:17:38 EDT
sorry jrd-1-image3.ps from comment #36 also fails with stack underflow
Comment 39 Michael Eager 2013-06-14 16:30:43 EDT
No joy.  Attachment 761437 [details] (Comment #37) also fails.
Comment 40 Alex Cherepanov 2013-06-14 16:34:03 EDT
Created attachment 761440 [details]
jrd-1-image4.ps

Please try this file. It has image data but doesn't display the image.
It should print a blank page.
Comment 41 John Dennis 2013-06-14 16:37:03 EDT
jrd-1-image4.ps behaved as expected, no error, printed a blank page.
Comment 42 John Dennis 2013-06-14 16:47:54 EDT
Here's a data point, not sure if it helps, but I've have this printer for years, it's always printed fine both from Linux and Windows, in fact it prints flawlessly from Windows today. It appears as if there is some change starting around F17 that's inducing these problems. I only say this because if you're wondering if it's the postscript interpreter in the printer that's at fault circumstantial evidence would suggest not, it seems to be recent Fedora related.
Comment 43 Michael Eager 2013-06-14 16:57:20 EDT
I'll echo John's comment.  I've confirmed that I have the latest PS interpreter firmware installed in the printer and it has been working for some long time.  I'm running F18.  I believe that this error appeared after an update, following which some email with graphics fail to print correctly.
Comment 44 Alex Cherepanov 2013-06-14 17:07:53 EDT
Created attachment 761442 [details]
jrd-1-image5.ps

Please try this file.
It has data, decompresses them and discards the result. Should print a blank page.
Comment 45 John Dennis 2013-06-15 07:45:03 EDT
jrd-1-image5.ps produces an ioerror from the readstring command.
Comment 46 Alex Cherepanov 2013-06-15 08:23:59 EDT
Created attachment 761574 [details]
jrd-1-image6.ps

Please try this file. It decompresses and discards data but introduces
explicit EOF marker in the input stream. The file should print a blank
page.

If it doesn't work, I'm out of ideas how to fix Level 3 data compression.
You can try to change %%LanguageLevel attribute in your PPD to 2
and re-generate your PS file.
Comment 47 John Dennis 2013-06-15 10:46:40 EDT
jrd-1-image6.ps printed as expected, blank page, no error.

With respect to LanguageLevel (see comment #35), how does one change it as a printer preference?
Comment 48 Alex Cherepanov 2013-06-15 11:06:50 EDT
Created attachment 761580 [details]
jrd-1-image7.ps

This file should have the image at the bottom of the page.
The file is similar to the previous one, but the data stream is directed to the
image code.

PostScript printer is described by its PPD file.
You can to find %%LanguageLevel attribute in the file and change its value from 3 to 2.
Comment 49 John Dennis 2013-06-15 17:16:20 EDT
jrd-1-image7.ps prints as expected, 1 image at the bottom of the page, nothing else on the page.

Yes, I saw the LanguageLevel in the PPD file, but what I was wondering is if that is connected to anything in any of the GUI configuration applets, it doesn't appear to be, but maybe I'm missing it. Also is LanguageLevel supposed to be related to BR-ScriptLevel in some manner?
Comment 50 Alex Cherepanov 2013-06-15 19:15:23 EDT
What's next?
We know now how to work around this bug in end-of-stream handling on this
kind of printers. The proposed code also works on correct PS interpreters.
I believe, it should be more robust in general than the original implementation.

Somebody has to contact pdftops folks and convince them to take a patch for
an odd off-brand printer. I's be glad to assist with PostScript issues.

PPD has interactive and non-interactive attributes. %%LanguageLevel is a
non-interactive one. Normally, a printer driver extracts relevant information
from PPD and generates appropriate PostScript stream from GDI calls.

Only Bother knows what BR-ScriptLevel actually means.I guess, it
approximately corresponds to PostScript language level.
Comment 51 John Dennis 2013-06-16 08:28:16 EDT
So out of curiosity is the problem:

1) incorrect postscript implementation in the printer

2) incorrect postscript generation

3) grey area of interpretation of what correct postscript is?

FWIW, I'm not sure I'd call Brother an "odd off-brand printer", they are a market leader and one of the best at supporting Linux and open source.
Comment 52 Alex Cherepanov 2013-06-16 10:02:48 EDT
The printer is, definitely, wrong here. Its FlateDecode filter has problems with
handling EOF condition.

The PostScript file is correct but inefficient and error-prone.
The code is difficult to adapt to images with multiple input
streams, for instance, separated images or masked images. The code also assumes
that the stack stays the same during execution of the image and filter
operators, which is not documented.

Experience shows, that the number of bugs in non-Adobe PostScript printers
is higher. Adobe OEM's must test their products for compatibility with all
major PostScript producers. The third parties don't have to do this.
Comment 53 John Dennis 2013-06-17 08:04:35 EDT
Thank you for your hard work Alex with diagnosing the problem, it's very much appreciated.

Where do we go from here?

Should a bug be filed with Brother concerning their EOF handling?

Can or should the postscript generator explicitly add an EOF marker to avoid the issue? Is this the path of least resistance and something which would be benign for postscript interpreters which do not have this problem? Should a bug be filed against pdftops for this?  

Should a bug be filed for pdftops concerning the issues you raised in comment #52?

Would changing the LanguageLevel to 2 in my PPD be an effective workaround or would I lose language features available at level 3 which I would want or need?

What is the precise problem with EOF handling? From your descriptions it sounds as if there is a data stream embedded in the file for images and the interpreter reads from that stream until it detect EOF. I also assume if it fails to detect EOF it will read past the end of the stream and consume a push, then when it returns to reading postscript the stack is now out of sync and it generates a stack underflow, is that correct?

What determines the EOF condition on an image stream?

I ask because it seldom hits this problem (working on the assumption all images are encoded the same way) because many documents with images print fine. Thus I would conclude there is some very specific condition that occurs only occasionally which causes the EOF to be missed. Can you identify what condition that is? (for instance something along the lines of:  image data is folded with a line length of N characters and EOF is not detected when the last line is exactly N characters long?)
Comment 54 John Dennis 2013-06-24 20:10:39 EDT
ping, any answers to the questions in comment #53?
Comment 55 Fedora End Of Life 2013-07-04 00:08:06 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 56 Matthew Saltzman 2013-07-04 03:49:06 EDT
Please update Fedora version. This is still an issue at least with F18.
Comment 57 Solomon Peachy 2013-08-11 19:43:33 EDT
This also affects F19 with my Brother HL-5340D. I've also seen this with an MFC-9770CDW.  In other words, this appears to affect several Brother printers.  

Setting *LanguageLevel: "2" seemed to help.  I don't know if I lost anything in doing so.

Anyway. I too look forward to some resolution here.
Comment 58 Tim Waugh 2013-08-12 06:09:48 EDT
All we can really do from this end is address the points raised in comment #52 (para 2) in poppler.  Changing component.
Comment 59 Lars Nielsen 2013-10-27 14:09:19 EDT
Also affect F19 with MFC-9840CDW
Comment 60 John Dennis 2013-10-28 10:20:43 EDT
What is the status of getting this fixed? The bug has been open for more than a year, it's root cause has been diagnosed, and it's affecting multiple users.
Comment 61 Fedora End Of Life 2013-12-21 03:50:18 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 62 Fedora End Of Life 2015-05-29 04:46:46 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 63 Fedora End Of Life 2015-11-04 06:43:51 EST
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 64 Fedora End Of Life 2015-12-01 21:40:42 EST
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 65 Solomon Peachy 2015-12-01 22:11:11 EST
This is *still* a bug, as of Fedora 22 and 23.  I am reliably able to make my Brother HL-5340D trigger this, using the manufacturer-supplied PPD (PS level 3)
Comment 66 John Dennis 2015-12-01 22:19:56 EST
Reopening, this problem is still present in F23.
Comment 67 Solomon Peachy 2016-05-01 23:51:28 EDT
As a random aside, I got hit again by this bug last night, on a fully up-to-date F23 box.

I'm able to work around the problem by generating postscript for the problematic pages (using evince) from the original pdf, then printing the postscript file (again using evince).

Nearly four years on, I'm wondering if this will ever be properly resolved...
Comment 68 John Dennis 2016-05-02 10:34:42 EDT
I continue to see the problem, also on a fully updated f23 system.
Comment 69 Solomon Peachy 2016-07-14 08:26:55 EDT
AAAaand this still is present in F24, which I suppose shouldn't surprise me.

We're now coming up on year three since the root problem was identified, and still no fix is pending.
Comment 70 John Dennis 2016-07-14 10:00:58 EDT
Not only has it been 3 years but I recently spent a lot of money to buy a new HP Multifunction printer to replace the otherwise perfectly fine Brother in large part because of this problem.
Comment 71 Fedora Admin XMLRPC Client 2016-10-14 04:07:12 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 72 Fedora End Of Life 2016-11-24 05:47:33 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 73 Fedora End Of Life 2016-12-20 07:25:18 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 74 Solomon Peachy 2018-01-15 20:09:24 EST
It's now over five years since this bug was reported and over four years since the problem was identified with a workaround identified, and the problem is *still* present and completely reproducible with Fedora 27.

Is there _any_ hope of movement on this?
Comment 75 Marek Kašík 2018-01-17 11:30:19 EST
I'll check this again but I won't get to it sooner than in February probably.

Note You need to log in before you can comment on or make changes to this bug.