Menu
▾
▴
gimp-print-devel
|
From: David R. <d_...@nc...> - 2000-03-27 01:55:46
|
> OK, I guess we`ll get rid of softweave mode on the 1520. That sounds kind of drastic, but I suppose if high speed microweave is supported by a given printer, it might obviate the need for softweave with that printer. I wonder the same issues would also apply to similar genre printers like the stylus color 800 and 850? Again, I'm not an expert at printer internals, but in case it might help, here's something I observed when testing the driver: When using the microweave mode, the printer advances the paper a small amount after every pass of the print head, whereas when using softweave, several passes (either three or four, I can't remember right now) are done before the paper is advanced; and when it is advanced, it is advanced the same small amount as it is during microweave. This probably accounts for the perceived speed difference - making microweave seem 3-4 times faster than softweave. >I know what`s wrong with the 1440x720 microweave. The fix won`t be >that hard, but it`s not entirely trivial either. It looks like this >really will need fixing. Once again, let me know when you have taken a cut at it and I'll test it out. For two years I've been looking forward to the moment I could print out a photo at 1440x720 from Linux and have it be as good as the same printed from Windows.. Regards, David |
|
From: Robert L K. <rl...@al...> - 2000-03-27 02:26:27
|
Date: Sun, 26 Mar 2000 16:35:02 -0800 From: David Rosky <d_...@nc...> > OK, I guess we`ll get rid of softweave mode on the 1520. That sounds kind of drastic, but I suppose if high speed microweave is supported by a given printer, it might obviate the need for softweave with that printer. I wonder the same issues would also apply to similar genre printers like the stylus color 800 and 850? If we can make softweave work, I'll happily put it back in, but if not, we can't use it. Again, I'm not an expert at printer internals, but in case it might help, here's something I observed when testing the driver: When using the microweave mode, the printer advances the paper a small amount after every pass of the print head, whereas when using softweave, several passes (either three or four, I can't remember right now) are done before the paper is advanced; and when it is advanced, it is advanced the same small amount as it is during microweave. This probably accounts for the perceived speed difference - making microweave seem 3-4 times faster than softweave. Could you time it with a stopwatch and verify that the times really are about equal (or that microweave does better)? >I know what`s wrong with the 1440x720 microweave. The fix won`t >be that hard, but it`s not entirely trivial either. It looks like >this really will need fixing. Once again, let me know when you have taken a cut at it and I'll test it out. For two years I've been looking forward to the moment I could print out a photo at 1440x720 from Linux and have it be as good as the same printed from Windows.. I'm working on it right now. |
|
From: David R. <d_...@nc...> - 2000-03-27 06:52:49
|
Robert L Krawitz wrote: > > > Could you time it with a stopwatch and verify that the times really > are about equal (or that microweave does better)? > OK, here are the timings. The image is 1272x1007 pixels and was being printed at about 42% scale (resulting image was about 9cm x 7.5cm). The machine is a 233MHz pentium Pro: MODE PROCESSING TIME PRINTING TIME TOTAL TIME 720x720 microweave 40 sec. 62 sec. 102 Sec. 720x720 softweave 40 sec. 101 sec. 141 Sec. As I had noticed previously, the microweave mode is somewhat faster. A few additional observations: In softweave, the head makes four passes before advancing the paper. In microweave mode, the driver places the image about 1cm or so lower on the page than in softweave mode (letter, portrait); and in both cases, the image is somewhat lower than one would assume from the print dialog. This doesn't happen when printing from Windows applications, so I assume it is not a printer issue. Regards, David |
|
From: Robert L K. <rl...@al...> - 2000-03-27 12:23:01
|
Date: Sun, 26 Mar 2000 21:32:04 -0800 From: David Rosky <d_...@nc...> In softweave, the head makes four passes before advancing the paper. In microweave mode, the driver places the image about 1cm or so lower on the page than in softweave mode (letter, portrait); and in both cases, the image is somewhat lower than one would assume from the print dialog. This doesn't happen when printing from Windows applications, so I assume it is not a printer issue. Actually, in softweave mode it should be alternating between several small advances and one larger advance, although normally they're fairly close to equal in spacing. The fact that there's a difference between the positioning of the softweave and the microweave is probably an artifact of the fact that the softweave isn't correct. What do you mean about the image being lower than one would assume from the print dialog? -- 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 The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: David R. <dav...@ts...> - 2000-03-28 18:54:59
|
Robert L Krawitz wrote: > > Actually, in softweave mode it should be alternating between several > small advances and one larger advance, although normally they're > fairly close to equal in spacing. OK. If the difference between the small steps and the big steps is not that great, then it might appear as if there is only one size step. > The fact that there's a difference > between the positioning of the softweave and the microweave is > probably an artifact of the fact that the softweave isn't correct. I figured that might be the case, which is why I thought it might be a notable symptom to report. Apparently the softweave code was taking four microscopic or zero sized steps (hard to tell the difference at 720dpi!) followed by one huge step. Another observation about 1440dpi: When the Windows driver is printing in 1440x720dpi, the head moves across the page at about half the speed as it does in 720dpi mode. I assume it does this in order to achieve the 1440dpi horizontal resolution using one horizontal head pass. > What do you mean about the image being lower than one would assume > from the print dialog? > The upper margin of the printable area for the 1520 is supposed to be 0.12". When I place the image all the way against the top margin in the gimp-print dialog box, I would expect the top edge of the image to be somewhere around 0.12" from the top of the page, plus or minus some amount for paper alignment errors. With the Windows driver, this is generally what I get. With the gimp-print driver, when using the working 720dpi microweave mode, the top of the image is somewhere around 0.5" to 0.75" from the top of the page. I am away from the printer right now, so I'm not sure of the exact number, but I can make an exact measurement for you in a few days. I'll also double-check the windows results (I haven't printed from windows for a while) and double check that the printer is loading the paper correctly. -David |
|
From: Robert L K. <rl...@al...> - 2000-03-29 02:28:15
|
Date: Tue, 28 Mar 2000 09:33:59 -0800 From: David Rosky <dav...@ts...> Robert L Krawitz wrote: Another observation about 1440dpi: When the Windows driver is printing in 1440x720dpi, the head moves across the page at about half the speed as it does in 720dpi mode. I assume it does this in order to achieve the 1440dpi horizontal resolution using one horizontal head pass. I *believe* that none of the printers can do 1440x720 in one pass; they all require (at least) two passes to do it -- some printers need four. The fact that you're only seeing one pass of the print head is immaterial; the head uses different jets to print each sub-pass. That reduces banding. The slower print speed is simply something the driver tells the printer to do; presumably it improves quality somewhat. We really need a GUI (and a system architecture) that allows the print driver to pass arbitrary printer-specific option choices through to the user. PDQ does a lot of this. It would be nice to figure out a way to leverage PDQ or snarf some of its code (I think it's GPL). The upper margin of the printable area for the 1520 is supposed to be 0.12". When I place the image all the way against the top margin in the gimp-print dialog box, I would expect the top edge of the image to be somewhere around 0.12" from the top of the page, plus or minus some amount for paper alignment errors. With the Windows driver, this is generally what I get. With the gimp-print driver, when using the working 720dpi microweave mode, the top of the image is somewhere around 0.5" to 0.75" from the top of the page. That's a limitation of the driver in its current form. I think I know how to get rid of that, although it will make for a bit more banding at the top, but it's going to be a fair bit of work to do. It's definitely something I want to fix before 3.2. It actually might be possible to get even closer than that, but let's do first things first. -- 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 The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: David R. <dav...@ts...> - 2000-03-29 18:08:59
|
Robert L Krawitz wrote: > > > I *believe* that none of the printers can do 1440x720 in one pass; > they all require (at least) two passes to do it -- some printers need > four. The fact that you're only seeing one pass of the print head is > immaterial; the head uses different jets to print each sub-pass. That > reduces banding. The slower print speed is simply something the > driver tells the printer to do; presumably it improves quality > somewhat. Maybe this can be determined by a timing experement with the windows driver. If the print head is moving at half the speed and the horizontal printing is done in one pass, then a 1440x720dpi image should take around twice as long to print as the same image at 720x720dpi (assuming the processing is fast enough to keep the print head in motion continuously, which is the case on my machine). If, however, two passes are required to print each horizontal raster line, then the 1440dpi image should take around four times longer to print (2x for the reduction in print head speed times 2x for the two passes). In any case I agree, though, that it would be good to allow more print head settling time at 1440dpi than at 720dpi. > > We really need a GUI (and a system architecture) that allows the print > driver to pass arbitrary printer-specific option choices through to > the user. PDQ does a lot of this. It would be nice to figure out a > way to leverage PDQ or snarf some of its code (I think it's GPL). > I wasn't familiar with PDQ, so I looked up its web page. It seems like a nice system and I think I'll try it out. With respect to gimp-print, since PDQ uses Ghostscript to render postscript, and since gimp-print has a Ghostscript driver manifestation, wouldn't the two already be able to work together? Presumably, gimp-print could receive printer-specific options from PDQ in the form of Ghostscript command line options. ?? > > That's a limitation of the driver in its current form. I think I know > how to get rid of that, although it will make for a bit more banding > at the top, but it's going to be a fair bit of work to do. It's > definitely something I want to fix before 3.2. It actually might be > possible to get even closer than that, but let's do first things > first. > I agree, it's not a big limitation at this point and functionality comes first. -David |
|
From: Robert L K. <rl...@al...> - 2000-03-30 00:10:41
|
Date: Wed, 29 Mar 2000 08:47:45 -0800 From: David Rosky <dav...@ts...> I wasn't familiar with PDQ, so I looked up its web page. It seems like a nice system and I think I'll try it out. With respect to gimp-print, since PDQ uses Ghostscript to render postscript, and since gimp-print has a Ghostscript driver manifestation, wouldn't the two already be able to work together? Presumably, gimp-print could receive printer-specific options from PDQ in the form of Ghostscript command line options. ?? Yes. I've written pdq descriptions; they're in Ghost/gs-stp.pdq. > That's a limitation of the driver in its current form. I think I know > how to get rid of that, although it will make for a bit more banding > at the top, but it's going to be a fair bit of work to do. It's > definitely something I want to fix before 3.2. It actually might be > possible to get even closer than that, but let's do first things > first. I agree, it's not a big limitation at this point and functionality comes first. OK. |
|
From: Robert L K. <rl...@al...> - 2000-03-27 02:46:43
|
OK, I've reenabled 1440x720 microweave. Let me know how it does. It's hideously slow on my EX. -- 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 The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: David R. <d_...@nc...> - 2000-03-27 07:43:36
|
Robert L Krawitz wrote: > > OK, I've reenabled 1440x720 microweave. Let me know how it does. > It's hideously slow on my EX. > Thanks for the fast turnaround. I tried it but it doesn't seem to be completely working yet. Here are the issues: 1) It's much much slower than the 720x720 microweave - it seems to be using only one or two nozzles as the paper advances microscopically with each pass. At first I thought the paper wasn't moving at all. 2) The image appears expanded by about 3x in the vertical dimension only. The expansion appears to be such that the vertical spacing between dots is also expanded, resulting in a decrease in overall density. 3) The colors seem to be much more red-ish. This may be an artifact due to the decrease in density caused by item 2, but I'm not sure of that. If fast microweave is only possible in 720x720, then unfortunately softweave may still be needed :( I'll be away from my printer for the next few days, but I'll check the list for any developments. -David |
|
From: Robert L K. <rl...@al...> - 2000-03-27 12:20:20
|
Date: Sun, 26 Mar 2000 22:22:51 -0800 From: David Rosky <d_...@nc...> 1) It's much much slower than the 720x720 microweave - it seems to be using only one or two nozzles as the paper advances microscopically with each pass. At first I thought the paper wasn't moving at all. That's what happens on the EX. The sequence in which the data is sent in microweave mode is not optimal, particularly for 1440x720. 2) The image appears expanded by about 3x in the vertical dimension only. The expansion appears to be such that the vertical spacing between dots is also expanded, resulting in a decrease in overall density. Hmm. That's very interesting. If fast microweave is only possible in 720x720, then unfortunately softweave may still be needed :( If so, you're going to need to test it. Try changing the "8" in the "64,8" to other values between 1 and 16 to see if anything else gives you better results. -- 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 The Gimp Print -- 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...> - 2000-03-27 13:59:46
|
Date: Sun, 26 Mar 2000 22:22:51 -0800 From: David Rosky <d_...@nc...> 1) It's much much slower than the 720x720 microweave - it seems to be using only one or two nozzles as the paper advances microscopically with each pass. At first I thought the paper wasn't moving at all. Let me know how it works now. -- 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 The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: David R. <dav...@ts...> - 2000-03-27 17:44:32
|
Robert L Krawitz wrote: > > > Let me know how it works now. > Will do, thanks. It'll be a few days, though, until I'm back at the computer with the 1520 attached. David |
|
From: David R. <d_...@nc...> - 2000-04-01 06:45:17
|
Robert L Krawitz wrote: > > > Let me know how it works now. > I have finally tried the 1.119 version and the results were different but still not correct. The magenta was horizontally offset from the cyan and yellow (by about 2cm to the right) and the density seems too low; however, the image was not expanded in the vertical dimension. The speed is still many, many, times slower than 720dpi, apparently still printing one or two nozzles at a time, with the paper advancing microscopically between scans. In order to help make the process less open-loop, I have taken Eric's suggestion and generated two files from the output of the Windows driver - one at 720dpi microweave, and the other at 1440 dpi microweave. To keep the file size down, the images are small, but they are big enough so that they are at least three or four times the height of the print head (which is fairly big on the 1520). The files should be accessable here: http://www.nccn.net/~w_rosky/dsr/e720.prn.gz http://www.nccn.net/~w_rosky/dsr/e1440.prn.gz A few more observations and comparisons regarding the Windows driver: 1) I timed the printing of an image in the 1440 and 720 "microweave" modes. The 1440dpi image took about four times longer to print (head in motion continuously), which seems to verify the assumption of two-pass printing. At 1440, the paper advances a small but visible amount between each scan of the head, and the head definitely moves more slowly than in 720dpi mode (somewhere around 1/2 speed), parhaps to allow increased settling time. 2) A manually fed piece of paper actually backs up a bit before the printing starts. Perhaps this is how they attack the problem of vertical offset on the page. I'm not sure if the driver or the application is doing this. 3) At 720dpi, the diffusion in the Windows output seems a bit more smooth with a little less graininess and patterning even in areas of medium density; however, the gimp-print driver seems to have better tonality and contrast (both drivers were used with default settings). Regards, David |
|
From: Robert L K. <rl...@al...> - 2000-04-01 15:02:18
|
Date: Fri, 31 Mar 2000 21:24:07 -0800 From: David Rosky <d_...@nc...> I have finally tried the 1.119 version and the results were different but still not correct. The magenta was horizontally offset from the cyan and yellow (by about 2cm to the right) and the density seems too low; however, the image was not expanded in the vertical dimension. The speed is still many, many, times slower than 720dpi, apparently still printing one or two nozzles at a time, with the paper advancing microscopically between scans. Hmm. That's interesting. How is the 720? Is that correct? http://www.nccn.net/~w_rosky/dsr/e720.prn.gz http://www.nccn.net/~w_rosky/dsr/e1440.prn.gz Thanks! 1) I timed the printing of an image in the 1440 and 720 "microweave" modes. The 1440dpi image took about four times longer to print (head in motion continuously), which seems to verify the assumption of two-pass printing. At 1440, the paper advances a small but visible amount between each scan of the head, and the head definitely moves more slowly than in 720dpi mode (somewhere around 1/2 speed), parhaps to allow increased settling time. I know that some printers have multiple head speeds. 2) A manually fed piece of paper actually backs up a bit before the printing starts. Perhaps this is how they attack the problem of vertical offset on the page. I'm not sure if the driver or the application is doing this. That happens on my EX, also. Does it happen differently with the plugin vs. Windows? |
|
From: David R. <d_...@nc...> - 2000-04-01 17:38:13
|
Robert L Krawitz wrote: > > > Hmm. That's interesting. How is the 720? Is that correct? > Actually, gimp-print's 720dpi microweave mode is very fast, on par with the print speed in Windows. The only difference is in the print quality, with Windows a little better in graininess and patterning and gimp-print a little better in tonality and contrast. > http://www.nccn.net/~w_rosky/dsr/e720.prn.gz > http://www.nccn.net/~w_rosky/dsr/e1440.prn.gz > > Thanks! > I should make one note on the files: The driver is the one that shipped with the printer when I bought it around two years ago. The driver has been updated several times since then by Epson but I haven't bothered to update it since I've not had any problems with it. To help with the gimp-print development, however, I'll download the newest version of the driver and generate new print files just in case there's been any change in the formatting of the data. > > That happens on my EX, also. Does it happen differently with the > plugin vs. Windows? Yes, the page does not back up any visble amount with the gimp-print plugin. It's hard to tell how much it's backing up with the windows driver because the reverse feed is immediately followed by a page advance, but it seems to be around 1/4 inch or so which would be about what is required to get the plugin's image up to the top of the page. -David |
|
From: Robert L K. <rl...@al...> - 2000-04-01 15:37:45
|
I have the files. It's quite different from anything I've seen before. On the 720 side, it looks like this: 00000058 1b ( G 01 00 01 0000005e 1b ( U 01 00 05 00000064 1b ( C 02 00 f0 1e 0000006b 1b ( c 04 00 4e 00 82 1d 00000074 1b U 01 00000077 1b ( e 02 00 00 02 0000007e 1b ( K 02 00 00 02 00000085 1b ( i 01 00 00 *0d ... 0002bce9 1b ( v 02 00 3d 00 0002bcf0 1b \ 09 0002bcf4 1b r 00 0002bcf7 1b . 01 14 05 40 00 05 (1280, 64) *0d 0002c2e2 1b \ 09 0002c2e6 1b r 01 0002c2e9 1b . 01 14 05 40 00 05 (1280, 64) *0d 0002e823 1b \ 09 0002e827 1b r 02 0002e82a 1b . 01 14 05 40 00 05 (1280, 64) *0d 00030f5b 1b \ 09 00030f5f 1b r 04 00030f62 1b . 01 14 05 40 00 05 (1280, 64) *0d 000330d4 1b ( v 02 00 3d 00 The basic unit is 1/720", and it's not using microweave. No surprise there. Just because Epson's driver calls it microweave doesn't mean that that's what the printer's doing. The 14 (hex; in decimal that's 20) indicates a vertical spacing of 20/3600" or 1/180" (on every other printer I've seen, in 720 dpi and higher that is locked to 5, or 5/3600" or 1/720"). The vertical advance is always 0x3d, or 61 (!) rows. Well OK, I *think* I see the logic here. This is really a (64,4) printer, but with a somewhat odd specification of the vertical spacing. My code prints (64,4) as three increments of 65 followed by one increment of 61. The Epson driver always advances by 61, but then there are three extra rows (the difference between 1/180" and 1/720" is 3/720"). The 1440 file is similar: 00000058 1b ( G 01 00 01 0000005e 1b ( U 01 00 05 00000064 1b ( C 02 00 f0 1e 0000006b 1b ( c 04 00 42 00 82 1d 00000074 1b U 01 00000077 1b ( e 02 00 00 01 0000007e 1b ( K 02 00 00 02 00000085 1b ( i 01 00 00 *0d 0000008c 1b ( v 02 00 eb 0c ... 0000444b 1b ( v 02 00 1f 00 00004452 1b \ 09 00004456 1b r 01 00004459 1b ( s 01 00 02 0000445f 1b . 01 14 05 3e 00 05 (1280, 62) *0d 00005130 1b \ 09 00005134 1b r 02 00005137 1b ( s 01 00 02 0000513d 1b . 01 14 05 3e 00 05 (1280, 62) *0d 0000619f 1b \ 09 000061a3 1b r 04 000061a6 1b ( s 01 00 02 000061ac 1b . 01 14 05 3e 00 05 (1280, 62) *0d 00007223 1b ( v 02 00 1f 00 0000722a 1b \ 09 0000722e 1b ( \ 04 00 a0 05 01 00 00007237 1b r 01 0000723a 1b ( s 01 00 02 00007240 1b . 01 14 05 3e 00 05 (1280, 62) *0d 00008241 1b \ 09 00008245 1b ( \ 04 00 a0 05 01 00 0000824e 1b r 02 00008251 1b ( s 01 00 02 00008257 1b . 01 14 05 3e 00 05 (1280, 62) *0d 00009769 1b \ 09 0000976d 1b ( \ 04 00 a0 05 01 00 00009776 1b r 04 00009779 1b ( s 01 00 02 0000977f 1b . 01 14 05 3e 00 05 (1280, 62) *0d It's interesting to note that they haven't optimized out the extra horizontal space commands (ESC\ is the old one that spaces in printer units; ESC(\ is the new one that can space in 1/1440"). This time, though, the vertical spacing is 0x1f (31) consistently. My driver does 33,29,29,29 spacing. I don't really understand the 31 spacing, though. I would have expected to see 29 (0x1d). Another mystery. So I'm not quite exactly certain how to interpret this, but I think I'm starting to see what's going on here. I don't know just when I'll get a chance to look at it, but if someone else wants to take a shot 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 The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X