I discovered a fairly nasty bug in 6-color mode in which there was a
discontinuity at the point that 6-color mode kicked in. Depending
upon the orientation of the gradient, the effect is either a dark line
of the color in question (cyan or magenta) or a white line. I had
thought it was a print head misalignment until I decided to take a
There was a related bug in 4-color mode; the symptoms probably would
be similar. In either event, there's a new version on my web site:
As for the issues I identified in my last message, here is how I
propose to handle them:
Notable issues with the current code (I consider all of these minor).
1) print.c is a real mess right now. All the settings-handling code
is ad hoc and very ugly, and there's a lot of knowledge scattered
about the code.
Not directly necessary to fix for release (unless someone wants to :-)
). However, cleaning this up may make fixing the save/load code
easier to fix.
2) As noted, the settings save/load code isn't perfect. It's OK for
beta (or development), but not really for a release.
Should be fixed for release.
3) Printing at 360 dpi (on the Stylus Photo) yields slightly reddish
grays. I'm not quite sure what to make of it. 360 dpi is proofing
resolution, and I'm not all that worried about perfection there
(I'm more concerned about a much smaller greenish or cyan cast at
720 dpi, and a possible slight blue-magenta cast in lighter tones).
I don't have a strong opinion on this. I consider 360 dpi mode to be
purely for proofing and I'm not overly concerned with details, but on
the other hand if people find the color cast too objectionable it
should be fixed.
4) The K->CMY code is distinctly tuned for the Stylus Photo EX right
now. Sorry, I don't have another color printer to play with.
This should be addressed, but it won't be unless we get testers.
5) The Stylus Photo printing has become very slow for some reason (at
least at 720 dpi). On the other hand, the microweave-induced
banding has entirely vanished, yielding much (arguably
spectacularly) better quality. I'm not positive exactly what did
this, but it's not at the top of my list of priorities to "fix".
If it takes 30 minutes to print a really high quality full-page
print that doesn't seem so bad.
Not to be fixed, since this "problem" improves output quality
substantially in the highest quality output mode.
6) Entirely get rid of the 8-bit rendering when the 16-bit rendering
is tested for all of the various rendering functions on a
reasonable variety of hardware.
Remove this code at release.
Robert Krawitz <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."