From: James K. <ja...@me...> - 2001-12-30 04:51:30
|
Hi, I'm having a problem using ghostscript-6.52 with gimp-print-4.2 and gimp-print-CVS. All print jobs to the Epson 1280 are getting truncated. If the print data is small enough, for example a few lines of text, nothing will print at all and blank sheets are ejected. If the print data is large, photos or text when the DPI is set very high, the print will be incomplete. I am printing from Linux (RedHat 7.2) through SMB to a windows box. I have verified that SMB is working fine and not causing the problem. I've tested this by printing to file on the windows box and then submitting the generated file through smbclient. This works without truncation. I've also tested printing using gimp instead of ghostscript and it exhibits the same truncation problem. This narrows the problem down to the ESC/P2 code generated by gimp-print. Any help would be appreciated. I would be happy to run more tests to troubleshoot the problem. Thanks, -James |
From: Robert L K. <rl...@al...> - 2001-12-30 14:42:26
|
From: James Klicman <ja...@me...> Date: Sat, 29 Dec 2001 20:51:25 -0800 I'm having a problem using ghostscript-6.52 with gimp-print-4.2 and gimp-print-CVS. All print jobs to the Epson 1280 are getting truncated. If the print data is small enough, for example a few lines of text, nothing will print at all and blank sheets are ejected. If the print data is large, photos or text when the DPI is set very high, the print will be incomplete. Sounds like you're running out of spool space (in /var/spool, /tmp, or the like). This is covered in the FAQ. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: James K. <ja...@me...> - 2001-12-31 10:02:15
|
Hi Robert, It's definitely not a spool problem (there is plenty of space). During testing I avoided the spool to eliminate it as a variable. I was generating ESC/P2 code using ghostscript (and gimp) then submitting it directly with smbclient. The print jobs were relatively small, all less than 10MB and the helloworld.ps test is only 90KB. Since the FAQ recommends submitting a bug report for the symptoms I've experienced, here is a simple test case. I executed ghostscript directly with the following arguments: gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=stp -sModel=escp2-1280 \ -sOutputFile=helloworld.escp2 helloworld.ps The contents of helloworld.ps: %! % Setup Epson 1280 % This has been tested with and without the following setup PostScript. <</PageSize[612 792]/ImagingBBox null>>setpagedevice % Letter 8.5in x 11in <</InputSlot(Standard)>>setpagedevice <</stpMediaType(Plain)>>setpagedevice <</InkType(PhotoCMYK)>>setpagedevice % Six Color Photo <</HWResolution[720 720]>> setpagedevice % ghostscript resolution <</Quality(720swuni)>> setpagedevice % printer resolution <</Color 2>> setpagedevice % BlackAndWhite <</ImageType 0>> setpagedevice % LineArt <</Dither(Adaptive)>> setpagedevice <</Gamma 1.0>>setpagedevice <</Density 1.0>>setpagedevice <</Brightness 1.0>>setpagedevice <</Saturation 1.0>>setpagedevice <</Contrast 1.0>>setpagedevice <</Cyan 1.0>>setpagedevice <</Magenta 1.0>>setpagedevice <</Yellow 1.0>>setpagedevice % Page content /Times-Roman findfont % Get the basic font 20 scalefont % Scale the font to 20 points setfont % Make it the current font newpath % Start a new path 72 72 moveto % Lower left corner of text at (72, 72) (Hello, world!) show % Typeset "Hello, world!" showpage The output of ghostscript is then submitted through smbclient: smbclient //foo/epson -I 10.0.0.10 -c 'print -' < helloworld.escp2 The result is the ejection of a blank page. -James On Sun, Dec 30, 2001 at 09:45:59AM -0500, Robert L Krawitz wrote: > From: James Klicman <ja...@me...> > Date: Sat, 29 Dec 2001 20:51:25 -0800 > > I'm having a problem using ghostscript-6.52 with gimp-print-4.2 and > gimp-print-CVS. > > All print jobs to the Epson 1280 are getting truncated. If the print data > is small enough, for example a few lines of text, nothing will print at > all and blank sheets are ejected. If the print data is large, photos or > text when the DPI is set very high, the print will be incomplete. > > Sounds like you're running out of spool space (in /var/spool, /tmp, or > the like). This is covered in the FAQ. > > -- > Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ > > Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 > Member of the League for Programming Freedom -- mail lp...@uu... > Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net > > "Linux doesn't dictate how I work, I dictate how Linux works." > --Eric Crampton |
From: Robert L K. <rl...@al...> - 2001-12-31 14:42:22
|
Date: Mon, 31 Dec 2001 02:02:08 -0800 From: James Klicman <ja...@me...> It's definitely not a spool problem (there is plenty of space). During testing I avoided the spool to eliminate it as a variable. I was generating ESC/P2 code using ghostscript (and gimp) then submitting it directly with smbclient. The print jobs were relatively small, all less than 10MB and the helloworld.ps test is only 90KB. ... The output of ghostscript is then submitted through smbclient: smbclient //foo/epson -I 10.0.0.10 -c 'print -' < helloworld.escp2 I don't think we have any Samba experts here (perhaps someone is?). You might try copying the file over (being careful to use binary mode with ftp) and sending it directly to the printer, or installing the printer on the Linux box and printing to it directly. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: James K. <ja...@me...> - 2001-12-31 19:41:39
|
Hi Robert, I explained in my original email that it is not an smbclient problem either. If I use "Print to File" on the windows box, copy the ESC/P2 generated by the windows driver to the Linux box and then smbclient print that file from the Linux box back to the windows box, it works fine. I also smbclient print to other machines and printers with no problems. I have tested the environment thoroughly and I am very confident the problem is with the ESC/P2 code generated by gimp-print. Your FAQ even lists this as a possibility. -James On Mon, Dec 31, 2001 at 09:44:28AM -0500, Robert L Krawitz wrote: > Date: Mon, 31 Dec 2001 02:02:08 -0800 > From: James Klicman <ja...@me...> > > It's definitely not a spool problem (there is plenty of > space). During testing I avoided the spool to eliminate it as a > variable. I was generating ESC/P2 code using ghostscript (and gimp) > then submitting it directly with smbclient. The print jobs were > relatively small, all less than 10MB and the helloworld.ps test is > only 90KB. > > ... > > The output of ghostscript is then submitted through smbclient: > smbclient //foo/epson -I 10.0.0.10 -c 'print -' < helloworld.escp2 > > I don't think we have any Samba experts here (perhaps someone is?). > You might try copying the file over (being careful to use binary mode > with ftp) and sending it directly to the printer, or installing the > printer on the Linux box and printing to it directly. > > -- > Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ > > Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 > Member of the League for Programming Freedom -- mail lp...@uu... > Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net > > "Linux doesn't dictate how I work, I dictate how Linux works." > --Eric Crampton |
From: Robert L K. <rl...@al...> - 2001-12-31 20:57:19
|
Date: Mon, 31 Dec 2001 11:41:32 -0800 From: James Klicman <ja...@me...> I explained in my original email that it is not an smbclient problem either. If I use "Print to File" on the windows box, copy the ESC/P2 generated by the windows driver to the Linux box and then smbclient print that file from the Linux box back to the windows box, it works fine. I also smbclient print to other machines and printers with no problems. I have tested the environment thoroughly and I am very confident the problem is with the ESC/P2 code generated by gimp-print. Your FAQ even lists this as a possibility. That's possible; I can't entirely rule it out. This would greatly surprise me, though; the 1280 is *very* similar to the 870, 1270, and 780, and these are among the best tested printers in the bunch; I have an 870 myself. Furthermore, Mogens Jaeger has been using a 1280 (specifically) with essentially perfect results (all he's had to do is slightly tweak the zero margin offsets). The reason I suspect the problem is either with running out of disk space somewhere or with samba is that 1) your symptoms match fairly closely common symptoms from running out of disk space, and 2) samba and disk space issues have historically been areas of trouble. Again, you may very well have stumbled across a real bug, but since the 1280 has proven reliable I'm inclined to suspect something else. The test with printing to file, copying the file over, and copying it back is not absolute proof. It is possible that newlines are being remapped both ways. If this is the case, printing to a file on Windows, copying to Linux, and copying it back will result in an unchanged file, but creating the file on Linux and copying it to Windows will break. However, I do note that you have been able to print to other printers. Again, I am not an expert at debugging Samba problems. It appears to me that you're using the default settings, which should be fine. How big is the print file that's being generated? If it's reasonable in size, you could send it to me and I could take a look at it. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: James K. <ja...@me...> - 2001-12-31 22:51:49
Attachments:
helloworld.escp2
|
Hi Robert, I had already thought of and ruled out a unix->dos remapping issue. Windows doesn't have a sum or md5sum command that I'm aware of so I can't easily compare byte for byte the original print file and the copy on Linux. However, they are the exact same size which indicates that no translation occurred since the file would shrink when "\r\n" is mapped to "\n". I can also see from the smbclient man page that it's 'get' command transfers in binary mode which is what I used to copy the file to Linux. In addition, the default printmode for my version of smbclient is graphics which also transfers in binary. I have also used: smbclient -c 'printmode graphics; print -' to remove any doubts. I understand your skepticism since the driver has been working for Mogens Jaeger. However, I did not email the list with a half-baked problem. If what I've presented is not absolute proof of a problem, I don't know how else to convince you. :-) I've attached two small test files. The first is the helloworld.escp2 example generated by ghostscript. The second file is a partial page of the README file from the EPSON documentation generated by the EPSON driver. I have only been able to print the first file once, after turning on the printer after it had been off overnight. Unfortunately, turning the printer off and on again does not allow me to print another copy. The second file I can print reliably. Could the windows driver be initializing the printer to a different state/mode than the gimp-print expects? Based on the fact that it works for Mogens and my assumption that he is printing directly from Linux and that I was able to print once after turning the printer on after being off overnight, that might explain the issue. -James P.S. I just realized that the one of the files is 300KB, not too big to email but I'm sure most people on the list don't want it. I'll send the files to you in a seperate email. On Mon, Dec 31, 2001 at 03:53:38PM -0500, Robert L Krawitz wrote: > Date: Mon, 31 Dec 2001 11:41:32 -0800 > From: James Klicman <ja...@me...> > > I explained in my original email that it is not an smbclient problem > either. > > If I use "Print to File" on the windows box, copy the ESC/P2 generated > by the windows driver to the Linux box and then smbclient print that > file from the Linux box back to the windows box, it works fine. I also > smbclient print to other machines and printers with no problems. > > I have tested the environment thoroughly and I am very confident the > problem is with the ESC/P2 code generated by gimp-print. Your FAQ even > lists this as a possibility. > > That's possible; I can't entirely rule it out. This would greatly > surprise me, though; the 1280 is *very* similar to the 870, 1270, and > 780, and these are among the best tested printers in the bunch; I have > an 870 myself. Furthermore, Mogens Jaeger has been using a 1280 > (specifically) with essentially perfect results (all he's had to do is > slightly tweak the zero margin offsets). > > The reason I suspect the problem is either with running out of disk > space somewhere or with samba is that 1) your symptoms match fairly > closely common symptoms from running out of disk space, and 2) samba > and disk space issues have historically been areas of trouble. Again, > you may very well have stumbled across a real bug, but since the 1280 > has proven reliable I'm inclined to suspect something else. > > The test with printing to file, copying the file over, and copying it > back is not absolute proof. It is possible that newlines are being > remapped both ways. If this is the case, printing to a file on > Windows, copying to Linux, and copying it back will result in an > unchanged file, but creating the file on Linux and copying it to > Windows will break. However, I do note that you have been able to > print to other printers. Again, I am not an expert at debugging Samba > problems. > > It appears to me that you're using the default settings, which should > be fine. How big is the print file that's being generated? If it's > reasonable in size, you could send it to me and I could take a look at > it. > > -- > Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ > > Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 > Member of the League for Programming Freedom -- mail lp...@uu... > Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net > > "Linux doesn't dictate how I work, I dictate how Linux works." > --Eric Crampton > > _______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
From: Robert L K. <rl...@al...> - 2001-12-31 23:12:13
|
Date: Mon, 31 Dec 2001 14:41:07 -0800 From: James Klicman <ja...@me...> I had already thought of and ruled out a unix->dos remapping issue. Windows doesn't have a sum or md5sum command that I'm aware of so I can't easily compare byte for byte the original print file and the copy on Linux. However, they are the exact same size which indicates that no translation occurred since the file would shrink when "\r\n" is mapped to "\n". I can also see from the smbclient man page that it's 'get' command transfers in binary mode which is what I used to copy the file to Linux. In addition, the default printmode for my version of smbclient is graphics which also transfers in binary. I have also used: smbclient -c 'printmode graphics; print -' to remove any doubts. OK; I'm not familiar with samba; I wanted to make certain that there were no issues of this kind. I understand your skepticism since the driver has been working for Mogens Jaeger. However, I did not email the list with a half-baked problem. If what I've presented is not absolute proof of a problem, I don't know how else to convince you. :-) Again, I'm not denying there's a problem; I'm just not yet convinced that the problem is in the driver rather than somewhere else. I've attached two small test files. The first is the helloworld.escp2 example generated by ghostscript. The second file is a partial page of the README file from the EPSON documentation generated by the EPSON driver. I have only been able to print the first file once, after turning on the printer after it had been off overnight. Unfortunately, turning the printer off and on again does not allow me to print another copy. The second file I can print reliably. So you *were* able to print it once. Very interesting. Normally I would think of this as a communication problem; if you were able to print it even once, it suggests that the file is indeed in the correct format. It certainly sounds like you've done a lot of work investigating the problem. How did you print the file the time you succeeded? Through samba, or by sending the file directly to the printer (whatever the Windows equivalent of "cat file > /dev/lp0")? Could the windows driver be initializing the printer to a different state/mode than the gimp-print expects? Based on the fact that it works for Mogens and my assumption that he is printing directly from Linux and that I was able to print once after turning the printer on after being off overnight, that might explain the issue. That's certainly possible; my examination of the output, via parse-escp2, doesn't show the Windows driver doing anything I wouldn't expect. Well, that's not quite true; it's using only 47 nozzles rather than 48, and it's setting up for a 1440 dpi basic dot spacing rather than 2880, but on the 1280 that should be fine (and it's doing the same for Mogens). I still really want to understand what happened the one time it did work. Can you try investigating what you can do to make it work? Also, try using the 1270 driver rather than the 1280 driver; if that makes a difference, it will be very interesting. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: James K. <ja...@me...> - 2002-01-01 00:08:33
|
On Mon, Dec 31, 2001 at 06:05:10PM -0500, Robert L Krawitz wrote: > I've attached two small test files. The first is the > helloworld.escp2 example generated by ghostscript. The second file > is a partial page of the README file from the EPSON documentation > generated by the EPSON driver. I have only been able to print the > first file once, after turning on the printer after it had been off > overnight. Unfortunately, turning the printer off and on again does > not allow me to print another copy. The second file I can print > reliably. > > So you *were* able to print it once. Very interesting. Normally I > would think of this as a communication problem; if you were able to > print it even once, it suggests that the file is indeed in the correct > format. It certainly sounds like you've done a lot of work > investigating the problem. Yes, a lot of work. Especially since the printer is upstairs in another room, so each test involves hiking up and down stairs. :-) > How did you print the file the time you succeeded? Through samba, or > by sending the file directly to the printer (whatever the Windows > equivalent of "cat file > /dev/lp0")? The one successful print was submitted through smbclient the same as every other attempt. > Could the windows driver be initializing the printer to a different > state/mode than the gimp-print expects? Based on the fact that it > works for Mogens and my assumption that he is printing directly > from Linux and that I was able to print once after turning the > printer on after being off overnight, that might explain the issue. > > That's certainly possible; my examination of the output, via > parse-escp2, doesn't show the Windows driver doing anything I wouldn't > expect. Well, that's not quite true; it's using only 47 nozzles > rather than 48, and it's setting up for a 1440 dpi basic dot spacing > rather than 2880, but on the 1280 that should be fine (and it's doing > the same for Mogens). Are there PostScript commands that I can use to duplicate what the Windows driver is doing? > I still really want to understand what happened the one time it did > work. Can you try investigating what you can do to make it work? > Also, try using the 1270 driver rather than the 1280 driver; if that > makes a difference, it will be very interesting. I used -sModel=escp2-1270 and the output file was slightly different, but the result was the same (blank page). One other thought I had, was that there could be an error in the file near the end. On small print jobs the printer error/ejects before outputting any ink. Large print jobs print almost to the end and result in an incomplete edge. I will send you scans of some of the incomplete print jobs. -James |
From: Robert L K. <rl...@al...> - 2002-01-01 15:57:12
|
Date: Mon, 31 Dec 2001 16:08:26 -0800 From: James Klicman <ja...@me...> > How did you print the file the time you succeeded? Through samba, or > by sending the file directly to the printer (whatever the Windows > equivalent of "cat file > /dev/lp0")? The one successful print was submitted through smbclient the same as every other attempt. Unfortunately, if we can't figure out what was different, it may be very hard to debug this. Are there PostScript commands that I can use to duplicate what the Windows driver is doing? No; the drivers simply take different approaches to generating output. One other thought I had, was that there could be an error in the file near the end. On small print jobs the printer error/ejects before outputting any ink. Large print jobs print almost to the end and result in an incomplete edge. I will send you scans of some of the incomplete print jobs. Does it vary depending upon the quality setting you use (360 DPI, 720 DPI, 1440x720, etc.)? -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: James K. <ja...@me...> - 2002-01-02 00:21:22
|
> One other thought I had, was that there could be an error in the > file near the end. On small print jobs the printer error/ejects > before outputting any ink. Large print jobs print almost to the end > and result in an incomplete edge. I will send you scans of some of > the incomplete print jobs. > > Does it vary depending upon the quality setting you use (360 DPI, 720 > DPI, 1440x720, etc.)? Yes, for example a high resolution print will only loose quality on the ending edge and a low resolution print may look very low quality (faint and noisy) like a layer of data is missing and have part of the print missing. I'll send you an example of a low-res print. -James |
From: Robert L K. <rl...@al...> - 2002-01-02 00:57:07
|
Date: Tue, 1 Jan 2002 16:21:15 -0800 From: James Klicman <ja...@me...> Yes, for example a high resolution print will only loose quality on the ending edge and a low resolution print may look very low quality (faint and noisy) like a layer of data is missing and have part of the print missing. I don't know what DPI you were using; 180 DPI wouldn't look terribly good on any paper, and 360 won't be solid on photo (or other high quality coated) paper. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: Simone F. <ka...@ti...> - 2002-01-02 23:25:00
|
Width this command "JE 0 0 0" inserted in deinizialization routine work fine in all resolution I get it from the windows driver sequence escp2_deinit_printer(const escp2_init_t *init) { stp_puts(/* Eject page */ "\014" /* ESC/P2 reset */ "\033@", init->v); if (escp2_has_advanced_command_set(init->model, init->v)) { stp_zprintf(init->v, /* Enter remote mode */ "\033(R\010%c%cREMOTE1", 0, 0); /* set up Roll-Feed options on appropriate printers (tested for STP 870, which has no cutter) */ if (escp2_has_cap(init->model, MODEL_ROLLFEED, MODEL_ROLLFEED_YES, init->v)) { if(strcmp(init->media_source,"Roll") == 0) stp_zprintf(init->v, /* End Roll Feed mode */ "IR\002%c%c%c", 0, 0, 0); else stp_zprintf(init->v, /* End non-Roll Feed mode */ "IR\002%c%c%c", 0, 0, 2); } stp_zprintf(init->v, /* Load settings from NVRAM */ "LD%c%c" "JE%c%c%c" // <<<<<<<<<<<<<<<<<<<<<<<<------- Width this command work fine /* Exit remote mode */ "\033%c%c%c", 0, 0, 1, 0, 0, 0, 0, 0); } } -----Messaggio originale----- Da: gim...@li... [mailto:gim...@li...]Per conto di Robert L Krawitz Inviato: Sunday, December 30, 2001 3:46 PM A: ja...@me... Cc: gim...@li... Oggetto: Re: [Gimp-print-devel] Epson 1280 Truncation/Incomplete printing From: James Klicman <ja...@me...> Date: Sat, 29 Dec 2001 20:51:25 -0800 I'm having a problem using ghostscript-6.52 with gimp-print-4.2 and gimp-print-CVS. All print jobs to the Epson 1280 are getting truncated. If the print data is small enough, for example a few lines of text, nothing will print at all and blank sheets are ejected. If the print data is large, photos or text when the DPI is set very high, the print will be incomplete. Sounds like you're running out of spool space (in /var/spool, /tmp, or the like). This is covered in the FAQ. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton _______________________________________________ Gimp-print-devel mailing list Gim...@li... https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
From: Robert L K. <rl...@al...> - 2002-01-03 00:27:08
|
From: "Simone Falsini" <ka...@ti...> Date: Thu, 3 Jan 2002 00:27:42 +0100 Width this command "JE 0 0 0" inserted in deinizialization routine work fine in all resolution I get it from the windows driver sequence Strange. This suggests that the JE command flushes data, or some such. I need to better understand what's going on, since not everyone using this printer seems to need it. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: James K. <ja...@me...> - 2002-01-03 00:39:42
|
THANK YOU, SIMONE FALSINI!!!!!! It works, it really works. It's printing "Hello, World" and the RedHat PostScript test page with no problems! :-) By the way, as I'm looking at the code, it should be outputting JE 1 0 0 not JE 0 0 0. Is that what you meant? Thank You! -James On Thu, Jan 03, 2002 at 12:27:42AM +0100, Simone Falsini wrote: > Width this command "JE 0 0 0" inserted in deinizialization routine work fine > in all resolution > I get it from the windows driver sequence > > escp2_deinit_printer(const escp2_init_t *init) > { > stp_puts(/* Eject page */ > "\014" > /* ESC/P2 reset */ > "\033@", init->v); > if (escp2_has_advanced_command_set(init->model, init->v)) > { > stp_zprintf(init->v, /* Enter remote mode */ > "\033(R\010%c%cREMOTE1", 0, 0); > /* set up Roll-Feed options on appropriate printers > (tested for STP 870, which has no cutter) */ > if (escp2_has_cap(init->model, MODEL_ROLLFEED, > MODEL_ROLLFEED_YES, init->v)) > { > if(strcmp(init->media_source,"Roll") == 0) > stp_zprintf(init->v, /* End Roll Feed mode */ > "IR\002%c%c%c", 0, 0, 0); > else > stp_zprintf(init->v, /* End non-Roll Feed mode */ > "IR\002%c%c%c", 0, 0, 2); > } > > stp_zprintf(init->v, /* Load settings from NVRAM */ > "LD%c%c" > "JE%c%c%c" // <<<<<<<<<<<<<<<<<<<<<<<<------- Width this command work > fine > /* Exit remote mode */ > "\033%c%c%c", 0, 0, 1, 0, 0, 0, 0, 0); > > } > } > > > -----Messaggio originale----- > Da: gim...@li... > [mailto:gim...@li...]Per conto di Robert > L Krawitz > Inviato: Sunday, December 30, 2001 3:46 PM > A: ja...@me... > Cc: gim...@li... > Oggetto: Re: [Gimp-print-devel] Epson 1280 Truncation/Incomplete > printing > > > From: James Klicman <ja...@me...> > Date: Sat, 29 Dec 2001 20:51:25 -0800 > > I'm having a problem using ghostscript-6.52 with gimp-print-4.2 and > gimp-print-CVS. > > All print jobs to the Epson 1280 are getting truncated. If the print data > is small enough, for example a few lines of text, nothing will print at > all and blank sheets are ejected. If the print data is large, photos or > text when the DPI is set very high, the print will be incomplete. > > Sounds like you're running out of spool space (in /var/spool, /tmp, or > the like). This is covered in the FAQ. > > -- > Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ > > Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 > Member of the League for Programming Freedom -- mail lp...@uu... > Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net > > "Linux doesn't dictate how I work, I dictate how Linux works." > --Eric Crampton > > _______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel > > > _______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
From: Robert L K. <rl...@al...> - 2002-01-03 01:12:07
|
From: James Klicman <ja...@me...> Date: Wed, 2 Jan 2002 16:39:34 -0800 THANK YOU, SIMONE FALSINI!!!!!! It works, it really works. It's printing "Hello, World" and the RedHat PostScript test page with no problems! :-) By the way, as I'm looking at the code, it should be outputting JE 1 0 0 not JE 0 0 0. Is that what you meant? It would either have to be JE 1 0 0 or JE 0 0 but JE 1 0 0 is probably the right thing. The first two bytes after the command name are the number of data bytes following, in little endian order. Therefore JE 1 0 means that there will be one more byte, while JE 0 0 would mean there would be no more bytes. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
From: Robert L K. <rl...@al...> - 2002-01-03 01:27:04
|
Folks, Could people with the 780, 790, 810, 820, 890, 895, 1280, and 1290 please try this patch (against 4.2)? |