Re: [Gimp-print-devel] Black generation, continued

[Robert L K. <rl...@al...>]

   Date: Mon, 22 May 2000 01:06:10 +0200
   From: Thomas Tonino <tt...@bi...>

   Robert L Krawitz wrote:

   > 1) The black is coming in too quickly on the 870, as you surmised.  I
   >    haven't tried the EX yet, but I suspect it would be even more
   >    noticeable.

   Wouldn't this be a matter of adjusting the lower and upper bounds for
   black?

It could be; k_lower and k_upper have changed effective meanings many
times now.

   While I'd rather have those corners smoothed. Any idea for a quick
   function? I'm thinking about scaling the beginning and end of the values
   to -1 and +1, and then doing 3*tk - tk*tk*tk as a transfer function.
   Makes a smooth curve and is not too slow.

It also needs long long arithmetic, which is significantly slower.

   > 2) The behavior at 720 dpi is significantly different -- there's much
   >    more black, and very dark regions look like they're not getting
   >    enough ink.

   I do not notice this with the 600, but that may be because I leave
   density at 1.

The density that you input is multiplied by the printer's density
setting (see printers.xml), which is about .6.

   In any case, I was happy to be able to use a lot of black if I wanted: I
   like to check pathological cases - they make me understand what goes
   wrong. But in this case, using a lot of black seemed to work fine.

The two issues with using a lot of black are:

1) Heavy black dots in areas not dark enough to mask them.

2) Insufficient total ink (if the black is at the expense of CMY) to
   fill everything in solidly (this varies with 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 The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton