Menu
▾
▴
gimp-print-devel
|
From: <sh...@al...> - 2000-03-03 12:26:59
|
> There's something here that doesn't make a lot of sense. Why on earth > does anyone need to *set* the printer resolution, anyway? Isn't it > fundamentally a property of the printer hardware? Nope. You figured it out. That's the trade secret. It's Epson's new adjustable with print head. I just issued the ESC ( D 0xff 0xff 0x01 0x01 command and printed out a new microprocessor microlithography mask at 65535 DPI. Epson doesn't want you to know that their printers can support this resolution, since they were planning on gradually re-releasing the same printer over and over again, over the next 10 years, with just a simple software change to support higher and higher resolutions. In fact, it was so secret, they didn't even tell their developer relations staff. Now they're ruined. Seriously, though, this makes some sense. In designing the new printer protocols, they simply moved the printer resolution from each individual raster transfer to once in the header. It's a sensible thing to do. Eric |
|
From: <sh...@al...> - 2000-03-04 09:45:21
|
> But this still doesn't entirely add up. The vertical spacing is a > hardware matter -- the jets are exactly such a distance a part, and no > amount of programming will change that. You are assuming softweave mode. But what about in microweave? Vertical resolution is determined solely by paper advances. I would imagine that they have some sort of stepper motor that does the advancing, rather than a continuous motor with a timed pulse, so you couldn't support arbitrary resolutions, but, probably quite a few more than are currently supported. > Unless by programming a > multiple of that you can turn off some of the jets? But to what end? I don't know. With RLE, you can zero out the line for a nozzle in just a few bytes, so, turning off a nozzle is cheap in terms of the amount of data you need to send over the bus, but, what does the printer do with that data when it is received? Is it kept RLE and decoded on the fly as the head moves? Or is it decoded into a RAM buffer before a pass? I suspect the latter. If you need to decode first, then, you can support longer lines by turning off jets since you won't need to allocate buffer space for all those zeros. Why do you want to turn off jets? The only reason I could think of would be if you wanted to print at a resolution was not an integer multiple of the jet spacing. The 750 has a jet spacing of 6/720 or 1/120. 360, 720, and 1440 are multiples of the jet spacing with factors of 3, 6, and 12. But what if you want to print at a resolution like 1140 DPI? That's 9.5*120. The first jet can print a line, but, the second jet cannot. It's not positioned properly. But the third jet can! You can actually use 24 of the 48 jets to achieve 1140 DPI assuming you can advance the paper that precisely. I don't know. It's weird. What I imagine is that none of the existing printers can really make use of this command because the stepper motors controlling paper feeds can't handle it, but, Epson is preparing for a long term strategy. There are probably some fancy printers in R&D now that can or may support this kind of thing and Epson is laying the groundwork in software early. This is, of course, all rampant and baseless speculation, but, it does seem to be consistent with the fact that someone at Epson obviously thought there was some need to keep this command secret. > The separations computed from the ESC(D > commands that we've seen don't match up to the print resolution. Yes, I do have to admit that that one perplexes me. When I get home I'll play with this command a bit more. Eric |
|
From: Robert L K. <rl...@al...> - 2000-03-04 14:11:15
|
From: sh...@al... Date: Sat, 04 Mar 2000 18:41:10 +0900 > But this still doesn't entirely add up. The vertical spacing is a > hardware matter -- the jets are exactly such a distance a part, and no > amount of programming will change that. You are assuming softweave mode. But what about in microweave? Vertical resolution is determined solely by paper advances. I would imagine that they have some sort of stepper motor that does the advancing, rather than a continuous motor with a timed pulse, so you couldn't support arbitrary resolutions, but, probably quite a few more than are currently supported. True, although ESC(D isn't used in microweave mode: $ hack-epson.new < 640-360.prn |more 00000000 1b @ 00000002 1b @ 00000004 1b ( R 08 00 00 52 45 4d 4f 54 45 31 *P *M *02 *00 *00 *00 *S *N *03 *00 *00 *00 *01 0000001e 1b *00 *00 *00 00000022 1b ( G 01 00 01 00000028 1b ( U 01 00 0a 0000002e 1b U 01 00000031 1b ( i 01 00 00 00000037 1b *19 *1 0000003a 1b ( e 02 00 00 03 00000041 1b ( C 02 00 71 10 00000048 1b ( c 04 00 17 00 ca 0f 00000051 1b ( S 08 00 a0 0b 00 00 71 10 00 00 0000005e 1b ( v 02 00 0d 00 Of course, given what you say below, it suddenly makes a lot more sense. I don't know. It's weird. What I imagine is that none of the existing printers can really make use of this command because the stepper motors controlling paper feeds can't handle it, but, Epson is preparing for a long term strategy. There are probably some fancy printers in R&D now that can or may support this kind of thing and Epson is laying the groundwork in software early. This is, of course, all rampant and baseless speculation, but, it does seem to be consistent with the fact that someone at Epson obviously thought there was some need to keep this command secret. That makes more sense than anything else I can come up with. -- 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-04 01:52:38
|
From: sh...@al... Date: Fri, 03 Mar 2000 21:23:05 +0900 Seriously, though, this makes some sense. In designing the new printer protocols, they simply moved the printer resolution from each individual raster transfer to once in the header. It's a sensible thing to do. But this still doesn't entirely add up. The vertical spacing is a hardware matter -- the jets are exactly such a distance a part, and no amount of programming will change that. Unless by programming a multiple of that you can turn off some of the jets? But to what end? It makes more sense in the horizontal direction, where inter-droplet separation has a certain amount of logic behind it, but even there it's a hardware matter. The separations computed from the ESC(D commands that we've seen don't match up to the print resolution. -- 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