On printer driver mass testing to test the buffered reading workaround for bug #689577 I discovered that the class of Epson MachJet drivers can get extremely slow or fall into an infinite loop on certain input files. The drivers are "mj500c", "mj700v2c", "mj6000c", "mj8000c". They all are based on the source code in contrib/japanese/gdevmjc.c (see contrib/contrib.mak). A command line example for testing is this one: cat encrpdf.ps | time gs -dBATCH -dPARANOIDSAFER -dNOPAUSE -sDEVICE=mj700v2c -sOutputFile=- -_ > x Ghostscript is simply running without showing anything on the screen and consuming 99% CPU. The file x stays at a size of 169 bytes, containing only output of Ghostscript, nothing from the driver.
Created attachment 3609 [details] Sample file which makes "mj..." drivers hang This file is the sample input file for the command line shown above. It is the output of Adobe Reader 8.1.1 printing an encrypted PDF into a file.
We cannot support this. Please contact the author. We will pay a bounty for a fix.
Cockpit error marked this as FIXED. Reopening.
Upstream authors of the driver informed by e-mail.
Contacting the authors and giving them the chance to collect the bounty did not help. Both e-mail addresses from the driver's source code do not exist any more.
Does the driver work with other files at all? My guess is the dither algorithm is buggy for some range of intemediate colours.
Hin-Tak, I think I did also mass testing with the CUPS test page. Please try with black text, perhaps the driver works in that case.
These 3 are fast: 1) b/w shapes (epl_test.ps from epsonepl) 2) color shapes (tiger.ps from ghostscript) 3) general color + text (cups's test page) but ghostscript is indeed stuck with the included ps file. The driver seems to be stuck somewhere on page one. I tried every device with fedora's shipped gs - and another device, photoex, also seems to be stuck, but most others are fine except two segfaults (filed separately as bug 690051 and bug 690052). Would be interesting to have a look what's in common with the photoex device.
Seems to be a problem with color encoding. I think I have a good chance of fixing this.
Created attachment 4357 [details] a patch that fixes the hang but very likely print with wrong colors This is a prototype patch which fixes the hang (but very likely have undesirable color changes) - the hang is simply due to bit-rot - the driver is missing encode_color/decode_color routines which is needed for postscript files with rendering intent. The API enhancement was introduced in 2002, and this driver simply has never picked up the API addition as it was always out-of-tree until recently. The corresponding change in the parent driver cdj (on which mjc was based) is svn r3320 in Nov 2002. Till: do you actually have this printer? Most likely this change will invert or swap colorants... it is easier just to print something to see which direction it needs to be modified than to try to look at the color mapping code :-).
Also, the photoex driver needs a similar change, as it is also a decendant of cdj and been out-of-tree until recently, and had suffered similiar bit-rot.
I do not have these printers. All changes I did were simply to keep the unmaintained driver building with all new Ghostscript versions coming up and having to be packaged for Mandriva and Ubuntu during the years.
Hin-Tak, I think we should wait for the Ghostscript developers to review your patch, they probably see immediately whether you have done the color stuff the right way.
I am quite sure the patch prints with wrong colors - possibly inverted or with colorants swapped. svn 3320, the corresponding change in the parent driver in 2002, renames the routines also inverts the color components. I haven't invert the color components yet (it is a bit more complicated than it sounds), but I have tested the change and it changes the file size of tests quite dramatically, e.g. from 0.5MB to 1MB and the opposite direction. In the absence of an actual printer, I guess the correct approach would be to try to invert the components and play with the code until there is no regression. It seems that adding the new routine hooks also changes behavior of the driver regarding to ps files not having rendering intent instructions.
Assigning to Michael to review Hin-Tak's patch, but without testing on the printer, it's hard to verify without a printer. Hin-Tak may be able to verify the correct colors by using a debugger and setting a breakpoint in the 'get_bits' call from the driver and check the colors that way.
Yes, the tips about get_bits is useful. I'll give it a try when I find the time.
According to OpenPrinting database MJ series includes Japanese versions of Epson Stylus printers. Common analogs are known for some of the printers supported by the Ghostscript driver. Perhaps, one of them can be used to test colors. MJ 8000C = Epson Stylus Color 3000. MJ-6000C = Epson Stylus Color 1520. MJ-930C = Epson Stylus Color 800.
Thanks for the tips - I'll have a look soon.
Created attachment 4710 [details] new patch new patch with more correct colour mapping.
Created attachment 4711 [details] a bunch of test files,t ar,gz'ed a bunch of test files, tar gz'ed. Some are plain solid colors (including white) , some are mods of the first page of the original sample with a different solid colour.
I am afraid I have some bad news - I think even with a postscript file without rendering intent, the driver code is just completely wrong and non-functional. This is shown by the fact that if you use the solid white/red/black colour pages in my attached bundle, the output is identical. Surely the printer data for whole red/white/black pages should not be the same. With my new patch, at least white pages (and pages which are mostly white) results in much smaller spool files than the other solid colors, and that has got to be more correct than the current driver code. The other driver, photoex, which hangs with the sample file mentioned in comment 8, also have the problem of identical spool files with the 4 pages of solid colors. i.e. it is also completely non-functional as is. So my suggestion would be: 1) if somebody has the Epson Stylus Color 3000/Epson Stylus Color 1520/Epson Stylus Color 800 that Alex mentioned in comment 17; give the new patch a try. At least the new patch shouldn't waste ink, unlike the current code, which possibly prints a mostly white page with a solid color of some sort. 2) I have also e-mail the author of the photoex driver, and see if I get a reply. It is not hopeful - the Machjet code is a derivative of the cdj driver in gs 2.61 15 years ago; and the photoex driver is likewise of gs 5.10 vintage from 1999-2001. Both sets of drivers have alternative drivers. So one is 15 years old and the other is 8 years old. 3) if Till or nobody has the Epson Stylus 800/1520/300 or the photoex printers (Epson Stylus Photo EX, Photo 700, etc), I think it would be advisable to remove both the drivers or disable them in default builds, since they are superceded by gutenprint. (in fact, the Photo Ex was apparently one of the printers which spawned the gimp-print project).
I think obsoleting the driver in the OpenPrinting database (in favor of Gutenprint) and removing it from Ghostscript would be generally a good idea. I only need to know about the following printers whether they work with Gutenprint and which model has to be selected under Gutenprint: 1. Epson MachJet (listed as supported by only "mj700v2c") 2. Epson Stylus (listed as supported by only "mj700v2c") 3. Epson Stylus Color 200 (listed as supported by only "mj500c") The printers are old, all only 360x360 dpi and the first two only BW. The driver entries "mj6000c" and "mj8000c" I can already mark obsolete as all printers there work with Gutenprint and have Gutenprint already as recommended driver. There is no "photoex" driver entry at all in the OpenPrinting database, probably as this driver was obsolete already as I started maintaining OpenPrinting. The Epson Stylus Photo EX was the printer with which the Gutenprint project was started.
Don't know if its any use, but I have an Epson Stylus Photo 870 here. I have no idea if its related to the problem though.
Hmm, the photo 870 might be useful for testing equivalent change in the photoex driver. (if we go that route). I'll wait a few days to see if the author of the photoex driver still reachable by e-mail though. In terms of long-term maintenance, I think both the mjc* and the photoex drivers are clearly non-functional at the moment because it is wrong that two solid colours should render to the same data steam. (please give it a try to double-check). The required change is I think what Dan Cosby did in r3320-ish for a bunch of drivers in 2002; my 2nd patch is roughly in the right direction, I think; since there seems to be better alternatives, there are various ways to go about this: 1) keep it in tree (as a sample of old/broken driver code?) and just document that it no longer works and not recommended in documentation and elsewhere. 2) make it optional, disable building either of them in the default config. e.g. make a new category of optional drivers which are known not-quite working, pending somebody interested enough and have the hardware to come along to fix it. 3) removing the code itself. OTOH, I hope the gimp-print/japanese people come up with some hardware, as an alternative to doing something is occasionally interesting to keep it around.
I have an Epson Stylus Color 200 printer and have been using this with the black print head with fedora 5 (mj500c) until a couple of weeks ago when I clean installed Fedora 11. This driver now gives a solid black image. Using the epson stylus color (not 200) stcolor driver allows correct printing of documents etc. Colour printing is still not correct. I posted a bug with red hat - please see https://bugzilla.redhat.com/show_bug.cgi?id=513676 for the details. I'm not sure if this issue is related to this bug If you need a printer for a test I'm happy to give it a try but please be reasonably explicit with any instruction.
Andrew: it is probably related... I'd probably like your to try my patch (or a test file generated from it), but before that, I'd want to see the result of "Colour printing is still not correct" from the stcolor driver first. Can you either scan or just take a digital picture of the result and attach it here? It doesn't need to be too high-res. Failing that, seeing as you have a uk adress you can probably spend 15p and an envelope, and post the result to me the old-fashioned way.
Created attachment 5278 [details] printer_test_mj500c
Created attachment 5279 [details] printer_test_stcolor
see comment 18 bugzilla redhat 513676. Attachments printer_test_mj500c test one image was raw file mj500c cups v1.1.x interpreter version 3010 (81501) printer_test_mj500c test two image was raw file mj500c cupsv1.2.x interpreter version 3010 (81502) printer_test_stcolor was stcolor.ppd driver version 1.1 cups 1.4rc1. Printer 'print test page' via system config printer properties
Closing due to lack of activity.