Bug 855009
We need more info. Output (after failing print job) from troubleshooter would be a good start. https://fedoraproject.org/wiki/Printing/Debugging#Printing_troubleshooter Created attachment 610388 [details]
output of troubleshoot
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' 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? same issue on Brother MFC-9440CN. 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 Same printer (Brother MFC-9840CDW), same frustrating progression of problems for me. Information is needed in order to make progress on fixing this bug. See comment #6. I see this behavior on a Brother HL-5250_DN as well. 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. 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* 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. 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. Created attachment 759298 [details]
CUPS job file
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
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
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 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. 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? 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.
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?
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 :-(
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? /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. 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... 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.
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. Created attachment 761385 [details]
Correctly printing one pg
I edited the failed.ps file (which prints correctly) to only print the first page.
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.
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.
New file prints OK. This matches my observation: the files which fail all have images. Created attachment 761405 [details]
jrd-1-image.ps
Please try this file. It has just the image.
jrd-1-image.ps gets stackunderflow error. Created attachment 761418 [details]
Change pop operations to cleartomark
Please try this file. It should be more tolerant to broken interpreters.
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. sorry, jrd-1-image2.ps from comment #34 also fails with stack underflow 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.
sorry jrd-1-image3.ps from comment #36 also fails with stack underflow No joy. Attachment 761437 [details] (Comment #37) also fails. 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.
jrd-1-image4.ps behaved as expected, no error, printed a blank page. 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. 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. 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.
jrd-1-image5.ps produces an ioerror from the readstring command. 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.
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? 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.
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? 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. 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. 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. 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?) ping, any answers to the questions in comment #53? 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. Please update Fedora version. This is still an issue at least with F18. 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. All we can really do from this end is address the points raised in comment #52 (para 2) in poppler. Changing component. Also affect F19 with MFC-9840CDW 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. 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. 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. 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. 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. 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) Reopening, this problem is still present in F23. 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... I continue to see the problem, also on a fully updated f23 system. 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. 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. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. 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. 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. 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? I'll check this again but I won't get to it sooner than in February probably. Today I tried failed.pdf and jrd-1.ps on Fedora 30 with the Brother HL-5250DN, and both printed successfully. Dare I say this might be fixed after all these years? (In reply to code from comment #76) > Today I tried failed.pdf and jrd-1.ps on Fedora 30 with the Brother > HL-5250DN, and both printed successfully. Dare I say this might be fixed > after all these years? I'm not sure, as my wife just ran into these symptoms when merely printing a JPG file to our Brother HL-5450DN. I've since reconfigured the default queue to use the pxlmono driver as a workaround, but have used a queue with the HL-5380DN BR-Script3 driver for testing. With this, failed.pdf prints fine here, but jrd-1.ps crashes the printer hard (lighting LEDs Toner/Drum/Error, indicating "Main PCB failure" which seems to me to be a fancy way for saying "our firmware crashed but we don't wanna hear about it"). I'll attach a JPG file reproducing the symptoms here, as well as the intermediate PDF file from the attempt to print it. Created attachment 1624416 [details]
JPG file reproducing the issue
Created attachment 1624417 [details] Intermediate PDF, as per comment #11 Both of the documents posted by Nils Philippsen (attachments 1624416 and 1624417) do fail for me. However, the error message on the paper differs from what I have seen before. Instead of a stack underflow message, it says:
ERROR NAME;
typecheck
COMMAND;
image
OPERAND STACK
I wonder if that is a separate bug or a variant of the original bug.
Meanwhile, jrd-1.ps still prints correctly for me.
If it matters, my printer is configured with the “Brother HL-5250DN Foomatic/Postscript” driver, not the “Brother HL-5250DN BR-Script3” driver,
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. 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 '30'. 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 30 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. Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 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. I'm sorry, but the problem is still present in Fedora 34, using Brother 5250DN. Please reopen the ticket. Beside the typical ""ERROR NAME; typecheck COMMAND; image OPERAND STACK;" ERROR i've seen also "ERROR NAME; memory full" (maybe after using xpdf, or trying to print PS file directly,don't know for sure). Strange, or maybe not, the problem is present also in Windows 10 using the default driver (which is also BR script 3, as far as i can see). The error was: "ERROR: limitcheck \n OFFENDING COMMAND: Type11Buidglyph \n\n STACK:" In Windows, using the latest driver from Brother (for windows 7?) fixes the problem. How can we 'downgrade' the driver in Fedora 34? Ive seen some workaround is mentioned. Can anybody clarified what is this workaround? My results are the same as they were in https://bugzilla.redhat.com/show_bug.cgi?id=855009#c80. I don’t know of any general workaround; the mentioned workaround was in https://bugzilla.redhat.com/show_bug.cgi?id=855009#c67: > 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). I’m not sure anyone with the necessary knowledge is ever going to revisit this. Nevertheless, I’ve reopened the bug and updated the version field to 34. Thank you. Here's what i've tried: Convert PDF to PS with pdf2ps, pdftops and evince. All three methods produce this type of file: "PostScript document text conforming DSC level 3.0, Level 2". Going to locaalhost 631 and configure my printer to PS level 2. None of this helped. I keep getting the 'typecheck' error. I have the necessary knowledge and some free time to finish this bug. In 2013 I found that pdftops utility from CUPS package generated correct, but hard to interpret PostScript file. I can check whether the current version of CUPS still has the same problem and post a patch on CUPS bug tracker. All other cases reported here, for instance the Type11Buidglyph one, look unrelated. I can check them out too, but let's track them separately. In all cases I need sample files, including the generated PostScript files, and detailed descriptions how to reproduce the problems. Hi Alex, thank you for helping on this. One file that fails with the 'typecheck' error is this attachment: Intermediate PDF, as per comment #11 (106.72 KB, application/pdf) 2019-10-10 16:48 UTC, Nils Philippsen Find it at the end of attachments of this ticket. To reproduce the error just open the document in evince and print it. If needed, i can generate the .ps with pdf2ps or pdftops. Please let me know if you need this also. This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. 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 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 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. Thank you for reporting this bug and we are sorry it could not be fixed. |
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.