QImage & Z3100 user here.
If not true 16 bit support (which would be a miracle given that windows only has an 8 bit graphics path), then at least internal 16 bit processing and dithering down to 8 bits for handover to the driver. This would take care of banding issues quite nicely.
[a href=\"index.php?act=findpost&pid=108779\"][{POST_SNAPBACK}][/a]
Internal calculations are done at 16 bit in most applications (Qimage as well) even when their in- and output is 8 bit.
Though Mike Chaney isn't convinced of the need for 16 bit in Qimage he also remarks that printer manufacturers could split the 16 bit data in two streams low and high bits or something like that, I'm not a software man. He has mentioned that at least two times.
In 2003 Mike gave an answer to similar questions:
I'm only telling you this because manufacturers could probably figure out a way to send 48 bit data through the normal Windows API print driver calls (such as sending two 24 bit images that overlay) but to do that, you'd have to have software that also used the same [clever] method of getting 48 bits to the driver which still amounts to specialized printing software to get the job done. Mike. End of quote.
There have been more discussions on the 16 bit issue on the Qimage mailing list. So there are ways to overcome the 8 bit limit in OS drivers. Outside the strict driver category there are several 16 bit print workflows meanwhile: ImagePrint claims to be 16 bit throughout, the Wasatch SoftRip is 16 bit for about a month now, GutenPrint is 16 bit internally, the Canon PS driver and there are more.
Ernst