Menu
▾
▴
gimp-print-devel
You can subscribe to this list here.
| 2000 |
Jan
(111) |
Feb
(412) |
Mar
(133) |
Apr
(187) |
May
(377) |
Jun
(355) |
Jul
(129) |
Aug
(316) |
Sep
(412) |
Oct
(258) |
Nov
(260) |
Dec
(228) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(291) |
Feb
(497) |
Mar
(341) |
Apr
(105) |
May
(127) |
Jun
(97) |
Jul
(348) |
Aug
(195) |
Sep
(353) |
Oct
(516) |
Nov
(454) |
Dec
(99) |
| 2002 |
Jan
(125) |
Feb
(232) |
Mar
(222) |
Apr
(160) |
May
(147) |
Jun
(97) |
Jul
(199) |
Aug
(275) |
Sep
(411) |
Oct
(355) |
Nov
(371) |
Dec
(326) |
| 2003 |
Jan
(314) |
Feb
(181) |
Mar
(166) |
Apr
(90) |
May
(192) |
Jun
(137) |
Jul
(91) |
Aug
(57) |
Sep
(59) |
Oct
(67) |
Nov
(202) |
Dec
(158) |
| 2004 |
Jan
(67) |
Feb
(81) |
Mar
(142) |
Apr
(124) |
May
(190) |
Jun
(245) |
Jul
(124) |
Aug
(199) |
Sep
(182) |
Oct
(92) |
Nov
(285) |
Dec
(173) |
| 2005 |
Jan
(111) |
Feb
(74) |
Mar
(90) |
Apr
(275) |
May
(133) |
Jun
(106) |
Jul
(215) |
Aug
(142) |
Sep
(131) |
Oct
(135) |
Nov
(75) |
Dec
(76) |
| 2006 |
Jan
(173) |
Feb
(96) |
Mar
(127) |
Apr
(226) |
May
(227) |
Jun
(83) |
Jul
(101) |
Aug
(122) |
Sep
(118) |
Oct
(27) |
Nov
(76) |
Dec
(58) |
| 2007 |
Jan
(204) |
Feb
(137) |
Mar
(115) |
Apr
(50) |
May
(135) |
Jun
(111) |
Jul
(57) |
Aug
(40) |
Sep
(36) |
Oct
(36) |
Nov
(77) |
Dec
(145) |
| 2008 |
Jan
(159) |
Feb
(52) |
Mar
(77) |
Apr
(59) |
May
(80) |
Jun
(105) |
Jul
(119) |
Aug
(225) |
Sep
(58) |
Oct
(173) |
Nov
(64) |
Dec
(94) |
| 2009 |
Jan
(61) |
Feb
(13) |
Mar
(70) |
Apr
(115) |
May
(48) |
Jun
(50) |
Jul
(34) |
Aug
(74) |
Sep
(30) |
Oct
(95) |
Nov
(132) |
Dec
(12) |
| 2010 |
Jan
(40) |
Feb
(22) |
Mar
(10) |
Apr
(5) |
May
(10) |
Jun
(73) |
Jul
(73) |
Aug
(74) |
Sep
(117) |
Oct
(33) |
Nov
(34) |
Dec
(41) |
| 2011 |
Jan
(42) |
Feb
(38) |
Mar
(60) |
Apr
(6) |
May
(26) |
Jun
(52) |
Jul
(16) |
Aug
(21) |
Sep
(49) |
Oct
(48) |
Nov
(64) |
Dec
(121) |
| 2012 |
Jan
(112) |
Feb
(81) |
Mar
(92) |
Apr
(37) |
May
(57) |
Jun
(142) |
Jul
(65) |
Aug
(43) |
Sep
(33) |
Oct
(81) |
Nov
(130) |
Dec
(63) |
| 2013 |
Jan
(63) |
Feb
(32) |
Mar
(80) |
Apr
(48) |
May
(44) |
Jun
(79) |
Jul
(86) |
Aug
(91) |
Sep
(43) |
Oct
(95) |
Nov
(130) |
Dec
(117) |
| 2014 |
Jan
(283) |
Feb
(206) |
Mar
(90) |
Apr
(57) |
May
(105) |
Jun
(66) |
Jul
(87) |
Aug
(30) |
Sep
(54) |
Oct
(125) |
Nov
(45) |
Dec
(36) |
| 2015 |
Jan
(58) |
Feb
(51) |
Mar
(59) |
Apr
(75) |
May
(70) |
Jun
(52) |
Jul
(58) |
Aug
(72) |
Sep
(184) |
Oct
(157) |
Nov
(91) |
Dec
(90) |
| 2016 |
Jan
(89) |
Feb
(61) |
Mar
(57) |
Apr
(86) |
May
(46) |
Jun
(63) |
Jul
(71) |
Aug
(60) |
Sep
(207) |
Oct
(139) |
Nov
(76) |
Dec
(68) |
| 2017 |
Jan
(112) |
Feb
(91) |
Mar
(138) |
Apr
(79) |
May
(36) |
Jun
(20) |
Jul
(105) |
Aug
(71) |
Sep
(51) |
Oct
(114) |
Nov
(148) |
Dec
(79) |
| 2018 |
Jan
(118) |
Feb
(107) |
Mar
(111) |
Apr
(127) |
May
(60) |
Jun
(63) |
Jul
(49) |
Aug
(18) |
Sep
(134) |
Oct
(68) |
Nov
(91) |
Dec
(27) |
| 2019 |
Jan
(41) |
Feb
(63) |
Mar
(37) |
Apr
(42) |
May
(44) |
Jun
(81) |
Jul
(53) |
Aug
(21) |
Sep
(62) |
Oct
(55) |
Nov
(41) |
Dec
(57) |
| 2020 |
Jan
(14) |
Feb
(29) |
Mar
(33) |
Apr
(20) |
May
(19) |
Jun
(9) |
Jul
(5) |
Aug
(23) |
Sep
(30) |
Oct
(29) |
Nov
(58) |
Dec
(139) |
| 2021 |
Jan
(62) |
Feb
(117) |
Mar
(13) |
Apr
(17) |
May
(23) |
Jun
(28) |
Jul
(7) |
Aug
(29) |
Sep
(56) |
Oct
(21) |
Nov
(36) |
Dec
(14) |
| 2022 |
Jan
(10) |
Feb
(28) |
Mar
(18) |
Apr
(19) |
May
(18) |
Jun
(3) |
Jul
(14) |
Aug
(11) |
Sep
(12) |
Oct
(4) |
Nov
|
Dec
(5) |
| 2023 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(2) |
Jun
(8) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(51) |
Aug
(31) |
Sep
(10) |
Oct
(14) |
Nov
(12) |
Dec
(14) |
| 2025 |
Jan
(17) |
Feb
(5) |
Mar
(30) |
Apr
(2) |
May
(4) |
Jun
(9) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Robert L K. <rl...@al...> - 2000-02-11 01:07:48
|
From: sh...@al... Date: Thu, 10 Feb 2000 20:49:29 +0900 > Hmm. I don't see how you're getting that seemingly negative number; I > just tried it and that didn't happen to me. I take it you have > updated recently? I update daily. The version that produced that output file was from a day or two ago. Checking the very latest version... still there. > Could you try softweave? Thanks. Similar: 00000051 1b ( / 04 00 4c ff ff ff The test image I'm printing is a small 360x240 JPG file. I've ajusted the scaling so this will be 2" wide on the page and positioned the top left corner of the image at the top left corner of the page (0,0). Could the left edge of the image position selection in the UI somehow be offset from the left edge in the page management coordinate system? The bug was real. It probably needs to be fixed, probably in exactly the same way, for Canon and HP printers, but since I don't know exactly how those printers work I left 'em alone for 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: Robert L K. <rl...@al...> - 2000-02-11 00:50:04
|
From: sh...@al... Date: Thu, 10 Feb 2000 20:49:29 +0900 > Hmm. I don't see how you're getting that seemingly negative number; I > just tried it and that didn't happen to me. I take it you have > updated recently? I update daily. The version that produced that output file was from a day or two ago. Checking the very latest version... still there. > Could you try softweave? Thanks. Similar: 00000051 1b ( / 04 00 4c ff ff ff The test image I'm printing is a small 360x240 JPG file. I've ajusted the scaling so this will be 2" wide on the page and positioned the top left corner of the image at the top left corner of the page (0,0). Could the left edge of the image position selection in the UI somehow be offset from the left edge in the page management coordinate system? Well, that's very, very interesting, especially since the offset from the left is specified as 9 points (= 90 page management units of 720 bpi) for the Epson printers. Yes, I think there's a real problem here. -- 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: Dave H. <da...@mi...> - 2000-02-10 12:58:02
|
Robert L Krawitz wrote: > > Date: Wed, 09 Feb 2000 14:51:21 +0000 > From: Dave Hill <da...@mi...> > > I have just tried printing some tests on my HP printer and I'm > getting an interesting image corruption. Basically, across the > bottom right of the image, there is a white patch followed by > a black patch at about 45 degrees. > > I have gone back through my snapshots and the problem appears > between 0205 and 0206 - i.e. when the dither stuff was changed/ > split out. > > Has anyone else seen this? > > I haven't seen any problems on my Epson Stylus Photo EX. Is your > printer a variable drop size printer or single drop size? Mono Single drop size, using dither_black(). > Oh foo, I think I know what the problem is. You're probably > seeing it in landscape mode, but portrait mode probably works > fine. No, this was in portrait mode. I then went on to try landscape and it's totally screwed up, you get the required output squashed horizontally into half of the page and junk in the other half! I think I'm going to have to write a "hp_unprint" program to save some paper! Dave -- Dave Hill, Kempston, Bedford UK da...@mi... Sicth munce ago, I cutn't evun spel enjuneer, and now I are one! |
|
From: Dave H. <da...@mi...> - 2000-02-10 12:57:53
|
> Is anybody still using Makefile.standalone? If not, I would like to > remove it. Yes, I am, because I build against a binary RPM of Gimp 1.0.4. But I could keep a copy myself! Dave -- Dave Hill, Kempston, Bedford UK da...@mi... Sicth munce ago, I cutn't evun spel enjuneer, and now I are one! |
|
From: <sh...@al...> - 2000-02-10 11:52:54
|
> Hmm. I don't see how you're getting that seemingly negative number; I > just tried it and that didn't happen to me. I take it you have > updated recently? I update daily. The version that produced that output file was from a day or two ago. Checking the very latest version... still there. > Could you try softweave? Thanks. Similar: 00000051 1b ( / 04 00 4c ff ff ff The test image I'm printing is a small 360x240 JPG file. I've ajusted the scaling so this will be 2" wide on the page and positioned the top left corner of the image at the top left corner of the page (0,0). Could the left edge of the image position selection in the UI somehow be offset from the left edge in the page management coordinate system? Eric |
|
From: Robert L K. <rl...@al...> - 2000-02-10 11:16:15
|
From: sh...@al... Date: Thu, 10 Feb 2000 14:43:57 +0900 > 00000008 1b ( U 05 00 02 02 01 a0 05 > : > 00000048 1b ( V 04 00 00 00 00 00 > 00000051 1b ( r 02 00 00 02 > 00000058 1b \ a6 ff > 0000005c 1b . 01 05 05 01 be 05 (1470, 1) *0d > [] > > Waitaminnit, what printer and what settings are you using? I have gimp-print set to ESP750, 720 dpi microweave, portrait letter paper, with the rest of the parameters near the middle of their range. Hmm. I don't see how you're getting that seemingly negative number; I just tried it and that didn't happen to me. I take it you have updated recently? This is currently the only setup I'm using for testing. Could you try softweave? Thanks. -- 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: <sh...@al...> - 2000-02-10 05:46:26
|
> 00000008 1b ( U 05 00 02 02 01 a0 05 > : > 00000048 1b ( V 04 00 00 00 00 00 > 00000051 1b ( r 02 00 00 02 > 00000058 1b \ a6 ff > 0000005c 1b . 01 05 05 01 be 05 (1470, 1) *0d > [] > > Waitaminnit, what printer and what settings are you using? I have gimp-print set to ESP750, 720 dpi microweave, portrait letter paper, with the rest of the parameters near the middle of their range. This is currently the only setup I'm using for testing. Eric |
|
From: Robert L K. <rl...@al...> - 2000-02-10 03:06:18
|
I turned on compiler warnings (-Wall) in Makefile.am. It turns out that I had introduced a bug or two (uninitialized variable) that wasn't being caught with default warnings. -- 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-02-10 00:32:42
|
Date: Wed, 09 Feb 2000 14:51:21 +0000 From: Dave Hill <da...@mi...> I have just tried printing some tests on my HP printer and I'm getting an interesting image corruption. Basically, across the bottom right of the image, there is a white patch followed by a black patch at about 45 degrees. I have gone back through my snapshots and the problem appears between 0205 and 0206 - i.e. when the dither stuff was changed/ split out. Maybe I should take this as a hint to stop messing up the infrastructure :-) -- 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-02-10 00:26:10
|
Date: Wed, 09 Feb 2000 14:51:21 +0000 From: Dave Hill <da...@mi...> I have just tried printing some tests on my HP printer and I'm getting an interesting image corruption. Basically, across the bottom right of the image, there is a white patch followed by a black patch at about 45 degrees. I have gone back through my snapshots and the problem appears between 0205 and 0206 - i.e. when the dither stuff was changed/ split out. Has anyone else seen this? Oh foo, I think I know what the problem is. You're probably seeing it in landscape mode, but portrait mode probably works fine. -- 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-02-10 00:22:23
|
Date: Wed, 09 Feb 2000 14:51:21 +0000 From: Dave Hill <da...@mi...> I have just tried printing some tests on my HP printer and I'm getting an interesting image corruption. Basically, across the bottom right of the image, there is a white patch followed by a black patch at about 45 degrees. I have gone back through my snapshots and the problem appears between 0205 and 0206 - i.e. when the dither stuff was changed/ split out. Has anyone else seen this? I haven't seen any problems on my Epson Stylus Photo EX. Is your printer a variable drop size printer or single drop size? |
|
From: Robert L K. <rl...@al...> - 2000-02-10 00:19:24
|
From: sh...@al... Date: Thu, 10 Feb 2000 00:10:46 +0900 Ok, I'm trying to follow the horizontal print head motions. Here's a section of ESCP2 output from gimp-print: 00000008 1b ( U 05 00 02 02 01 a0 05 : 00000048 1b ( V 04 00 00 00 00 00 00000051 1b ( r 02 00 00 02 00000058 1b \ a6 ff 0000005c 1b . 01 05 05 01 be 05 (1470, 1) *0d 0000010c 1b ( r 02 00 00 01 00000113 1b \ a6 ff 00000117 1b . 01 05 05 01 be 05 (1470, 1) *0d 00000176 1b ( r 02 00 00 04 0000017d 1b \ a6 ff 00000181 1b . 01 05 05 01 be 05 (1470, 1) *0d 00000245 1b ( r 02 00 01 02 0000024c 1b \ a6 ff Waitaminnit, what printer and what settings are you using? -- 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-02-10 00:16:06
|
From: sh...@al...
Date: Thu, 10 Feb 2000 00:10:46 +0900
Ok, I'm trying to follow the horizontal print head motions. Here's a
section of ESCP2 output from gimp-print:
00000008 1b ( U 05 00 02 02 01 a0 05
:
00000048 1b ( V 04 00 00 00 00 00
00000051 1b ( r 02 00 00 02
00000058 1b \ a6 ff
0000005c 1b . 01 05 05 01 be 05 (1470, 1) *0d
0000010c 1b ( r 02 00 00 01
00000113 1b \ a6 ff
00000117 1b . 01 05 05 01 be 05 (1470, 1) *0d
00000176 1b ( r 02 00 00 04
0000017d 1b \ a6 ff
00000181 1b . 01 05 05 01 be 05 (1470, 1) *0d
00000245 1b ( r 02 00 01 02
0000024c 1b \ a6 ff
Roughly translated to English it's:
Use 1/720" page 1/720" vertical and 1/1440" horizontal units
:
Right. It's interesting that it's using the ESC\ command, but for now
we'll let that pass.
Move to top of page
Select color cyan
Move left 90*1/1440"
Print at 720 DPI one line of 1470 pixels with an extra 0xd at the end (???)
That extra 0xd is a carriage return.
Select color magenta
Move left 90*1/1440"
Print at 720 DPI one line of 1470 pixels with an extra 0xd at the end (???)
etc.
My question is, why is it only moving 90 ticks to the left when it's printing
2940 ticks to the right? The printer head should hit the right edge of the
page in no time this way, no? What am I missing?
Urgh. This -90 ticks looks like a problem. Perhaps this is what's
causing all the grief?
--
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: <sh...@al...> - 2000-02-09 15:12:52
|
Ok, I'm trying to follow the horizontal print head motions. Here's a
section of ESCP2 output from gimp-print:
00000008 1b ( U 05 00 02 02 01 a0 05
:
00000048 1b ( V 04 00 00 00 00 00
00000051 1b ( r 02 00 00 02
00000058 1b \ a6 ff
0000005c 1b . 01 05 05 01 be 05 (1470, 1) *0d
0000010c 1b ( r 02 00 00 01
00000113 1b \ a6 ff
00000117 1b . 01 05 05 01 be 05 (1470, 1) *0d
00000176 1b ( r 02 00 00 04
0000017d 1b \ a6 ff
00000181 1b . 01 05 05 01 be 05 (1470, 1) *0d
00000245 1b ( r 02 00 01 02
0000024c 1b \ a6 ff
Roughly translated to English it's:
Use 1/720" page 1/720" vertical and 1/1440" horizontal units
:
Move to top of page
Select color cyan
Move left 90*1/1440"
Print at 720 DPI one line of 1470 pixels with an extra 0xd at the end (???)
Select color magenta
Move left 90*1/1440"
Print at 720 DPI one line of 1470 pixels with an extra 0xd at the end (???)
etc.
My question is, why is it only moving 90 ticks to the left when it's printing
2940 ticks to the right? The printer head should hit the right edge of the
page in no time this way, no? What am I missing?
And why does the relative motion preceed the printing? Should it come
afterward?
Eric
|
|
From: Dave H. <da...@mi...> - 2000-02-09 14:53:37
|
Hi I have just tried printing some tests on my HP printer and I'm getting an interesting image corruption. Basically, across the bottom right of the image, there is a white patch followed by a black patch at about 45 degrees. I have gone back through my snapshots and the problem appears between 0205 and 0206 - i.e. when the dither stuff was changed/ split out. Has anyone else seen this? Dave Hill -- Dave Hill, Kempston, Bedford UK da...@mi... Sicth munce ago, I cutn't evun spel enjuneer, and now I are one! |
|
From: <sh...@al...> - 2000-02-09 12:02:36
|
All of the data I'm currently generating with gimp-print seems to terminate in the middle of a raster transfer. Has anyone else noticed this? Now that I've cleaned up my memory problems in unprint.c I can actually read in the whole file without segfaulting. But then the file just ends unexpectedly. I'm using the latest CVS version set to ESP750 microweave. Eric |
|
From: Karl H. K. <kh...@kh...> - 2000-02-09 11:56:50
|
=2E.. actually no new results, just new tests, the results are
still the same: I was not able to get the printer yesterday
evening,so it took me a little longer to test the new and=20
improved stc740 softweave handling: I tested both variable
and single dot sizes and with both settings the behavior
is still the same: The printer basically just spits out the
paper. I am also not so sure that the vertical movement is
really to the place where the image should be. I did my
latest tests with a very small image that I moved around on
the page and the printer always moves to about the middle
of the page first (vertically) and stops there for a split
second and then moves on.
Karl Heinz
--=20
Karl Heinz Kremer kh...@kh...
http://www.khk.net
ICQ: 41190739
|
|
From: Robert L K. <rl...@al...> - 2000-02-09 11:11:24
|
From: sh...@al... Date: Wed, 09 Feb 2000 16:12:45 +0900 > > In microweave mode it isn't using multibit at all. > > Oh, really? Then something is pretty snafu. > > Why, is microweave mode trying to use multibit mode? I thought I > explicitly disabled that last night. I just meant that it was being initialized as multibit with ESC ( e 16 yet the older print raster commands were being used. It was inconsistent. Ah. I won't have time to fix that this morning. -- 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: <sh...@al...> - 2000-02-09 07:15:08
|
> > In microweave mode it isn't using multibit at all. > > Oh, really? Then something is pretty snafu. > > Why, is microweave mode trying to use multibit mode? I thought I > explicitly disabled that last night. I just meant that it was being initialized as multibit with ESC ( e 16 yet the older print raster commands were being used. It was inconsistent. Eric |
|
From: Robert L K. <rl...@al...> - 2000-02-09 03:01:46
|
I moved the lut into the vars struct. It isn't currently saved as part of the printrc file; that will come later presumably, but I wanted to prepare for that. I didn't actually move the call to compute_lut, though. |
|
From: Robert L K. <rl...@al...> - 2000-02-08 23:37:04
|
Is anybody still using Makefile.standalone? If not, I would like to remove it. |
|
From: Robert L K. <rl...@al...> - 2000-02-08 23:16:26
|
Date: Tue, 08 Feb 2000 18:54:06 +0100 From: Andy Thaller <th...@ph...> Robert L Krawitz wrote: > Right, use dither_cmyk4. mmm - right :-) Guess I'm too tired today. Anyway, checked in new drop size stuff code ready for testing (can't expect to test it myself tonight). dither_cmyk4() doesn't produce more than one level per component, though. Think I've got everything right this time, but I've erred before ;-) Hmm, I just tested it, and dither_cmyk4() produced multiple levels just fine for me. PS: I've got a canon-unprint tool but it's written in (quick'n'dirty) C++ -- if anyone is interested I can add it to the repository or maybe port it to C first. Go right ahead and add it. There's nothing wrong with this kind of thing being in C++. -- 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-02-08 23:14:48
|
From: sh...@al... Date: Tue, 08 Feb 2000 21:16:55 +0900 > In microweave or softweave mode? I'm working exclusively in microweave mode at the moment. It seems to be the simpler case. > In microweave mode it isn't using multibit at all. Oh, really? Then something is pretty snafu. Why, is microweave mode trying to use multibit mode? I thought I explicitly disabled that last night. > I thought I had fixed the softweave code (and I know > I've tested it) to use ESCi in multibit mode. ESC. will not do > multibit stuff; there's no way to express it. That's not entirely true. The printer is initialized to expect a particular bit depth with the "ESC ( e" command. When the command is called with 0x10, the printer is put in multibit mode, with lower numbers it's single bit. I expect there's some register in the printer that gets set to remember the bit depth. Eric _______________________________________________ Gimp-print-devel mailing list Gim...@li... http://lists.sourceforge.net/mailman/listinfo/gimp-print-devel |
|
From: Robert L K. <rl...@al...> - 2000-02-08 17:29:52
|
Date: Tue, 08 Feb 2000 15:08:38 +0100 From: Andy Thaller <th...@ph...> Andy Thaller wrote: > Ok, I tried it.. To check things out I'm not yet folding the output but > leaving things as they are. this should give me two pictures the left being > the lsb and the right the msb. however, only the first line of the dithering > output actually contains any pixels. To illustrate this, I've put the input > and output on http://www.ph.tum.de/~thaller/gimp-print/ Ok, found it - dither_black is the wrong function, dither_black4 does the right thing. However, dither_cmyk also doesn't use more than 2 levels, right? Anyway, I'm happy it works for 4 black levels - I've put the output on the page mentioned above so you can have a look :-) Right, use dither_cmyk4. |
|
From: Robert L K. <rl...@al...> - 2000-02-08 17:28:31
|
Please test softweave. |
137 messages has been excluded from this view by a project administrator.
