@Nicholas Jordan wrote:
plus the device independent bitmap and making the data ( therein ) available to what Java calls a pixel grabber is going to be learning Data Source Manager … where’s the sources for that?
( I’m in over my head, I have never done graphics )
You don’t need to send the in-memory DIB to Java. You can write it to a BMP file from C code (using the Windows API) and send the path(s) to Java. The TWAIN Data Source Manager is not involved in that part, you just quoted a function call that opens the device for scanning, and another (OpenFile) which is unrelated to TWAIN.
You can also implement different transfer modes (buffered, disk) that depending on the capabilities of the scanner will make the image available as already compressed JPGs, PNGs, TIFs, etc.
The TWAIN specs describe in depth how to implement those modes and the different image file formats that *might* be available on the scanner.
My extensions to the EZTWAIN classic library implement disk transfers to request data from the scanner to be saved directly to G4 compressed TIFs and JPEGs. Unfortunately my company doesn’t allow me to share code, but I can tell you that the implementation is short and mostly painless once you understand the concepts, as long as you’re comfortable with C/C++.