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 closer look. 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: http://www.tiac.net/users/rlk/print.tar.gz. 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 <rlk@xxxxxxxxxxxx> 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 lpf@xxxxxxxxxxxx "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
