Menu
▾
▴
Re: [Gimp-print-devel] RE: Epson 1520 issues
|
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 |
