Scanner as mount point?

A printer is not normally apriori an input device.

Today, an "all-in-one" may be functional as a flatbed image aquisition device.

Given:

Code:

---

G:\
 is mount point.
H:\
 is mount point.
I:\
 is mount point.
J:\
 is mount point.

---

and so on, how would we do a file read on the image aquire? Note, this is very easily confused with

Code:

---

Scanner sc = new Scanner(new File("myNumbers"));
while (sc.hasNextLong()) {
long aLong = sc.nextLong();}

---

which is not [][] or [] as raw image data. I already have a runtime loadable lib started and headers pulled from some get-going wrapper code I wrote in Java: compseconcepts.info + there is an image aquisition run-time loadable lib with which I can get the [][] or [] into addressable process ram. There is an intermediary body of code that will discover what devices are mounted that can do this and provide calls to get the image data going through calls approved by the hardware vendor, what I guess I am stuck on is the JNI stuff.....

Apparently the DIB maps into a lookup table, giving triplets of octets, okay - so how to get from there to ImageReader? ( or what is the appropriate java class to use (?) ) I found some code at Java Programming - Java and OCR which would very very likely be a good place to work to, so how do I get from a dib to the code that person posted?

Well, I see where your quiz question came from...

Unless the OS presents the scanner to Java as a "File", no. There may be other parts of the device that the OS treats as a "File". In that case, the scanner *might* be able to save the scanned image to the internal storage device.

Quote:

---

Originally Posted by Steve11235

Well, I see where your quiz question came from...

---

which one?

Quote:

---

Originally Posted by Steve11235

Unless the OS presents the scanner to Java as a "File", no. There may be other parts of the device that the OS treats as a "File". In that case, the scanner *might* be able to save the scanned image to the internal storage device.

---

There is a body of code, I am tempted to call it a "driver" but that name though correct does not fully describe what the "driver" actually does. You talk to the loadable runtime, it talks to the device and OS - that tool can do any optimization it wants including negotiate issues such as may be other parts of the device that the OS treats as a "File" There does seem to be an issue on message loop being used to provide state information, but a simplified version of the header file that calls into the primary dll has a simple hook avaliable for use.

I extracted the text for the spec, it runs 829 KB (849,356 bytes) - that is the spec. The dll is somewhat bulky by some people's ideas but we can make one call in the simplified header and it will do the boolean isAvailable() and boolean loadDLLmain() and so on using a simplified set of calls.

I rewrote my Java wrapper code, ran javah on it and put up the first revision at the link posted earlier. I was about ready to run some limited C code, the author of the simplified version provided review on which function call I selected for KISS first run, what I think I am needing to get to is to "construct" a

Code:

---

java.awt.image.DataBufferByte;

---

from the DIB returned by the C call,.... in over my head but I am confident what I need to do is get the DIB returned from the C call into Java where we have BufferedImage available to begin work as posted at the Sun post I linked.

In my mind, I have both sides ready - cannot hook it together because of lack of JNI experience.

The one about mount points.

I would suggest creating a class that can interact with the DLL through JNI directly. The alternative would be for the DLL to "act" like a mount point, which would make the DLL more complicated and also require OS intervention.

I'm not a C/C++ programmer, but I'm sure you can keep the external interface to the DLL simple while hiding the complexity of the operations involved in dealing with the scanner. Have the DLL do as much work as possible.

Ideally, it should just provide the information the JNI piece needs to construct an image, in the format Java needs.

Quote:

---

Originally Posted by Steve11235

I would suggest creating a class that can interact with the DLL through JNI directly. The alternative would be for the DLL to "act" like a mount point, which would make the DLL more complicated and also require OS intervention.

---

It will, the simplified one will do all the OS negotiation and as well provides a simplified interface that uses a simplified call syntax that is consistent with Java call syntax. I have not dug into the larger dll nor another one that can do much of what I have intent to work on in Java. Both of them appear at this point to do all the "mount point" negotiation as well as provide a place for equipment vendors to do the work there as they see fit.

Quote:

---

Originally Posted by Steve11235

I'm not a C/C++ programmer, but I'm sure you can keep the external interface to the DLL simple while hiding the complexity of the operations involved in dealing with the scanner. Have the DLL do as much work as possible.

---

It does, at this point my challenge is to get a raw byte stream as a DIB into Java, for which I selected one of the image classes as the comments stated it did not consider signed / unsigned to be of syntactic significance. EZTwain calls into Twain Source Manager (Image Acquisition Interface) which is a dll provided in the system folder - there are about 3 to 5 dll's I am getting positioned in my mind, EZTwain will call into the actual system libs in a manner that retires my "mount point" labels

Code:

---

if(File.isAbsolute()){Console.println("mount point"));}

---

in the original post, that was some duck tape code I wrote yesterday to see if File.listRoots() would tell me if the scanner was mounted as a system device.

What I conclude at this point is that rather than trying to "mount" - what I do is use the EZTwain dll, which is provided both in source code and as a compiled run time library. I got ahead of myself using the terminology "mount point", that was exploratory code.

Quote:

---

Originally Posted by Steve11235

Ideally, it should just provide the information the JNI piece needs to construct an image, in the format Java needs.

---

That is where I am at right now, we know factually from replies at the correct forum by the author of EZTwain that I can do one function call from my dll into that dll and get - if available - a "graphic",.....which is returned in the form of a DIB. it will do *all* the if(available())then mount() + get image and so on, safely.

What I need to do is construct a DataBufferByte thusly:

Code:

---

private native java.awt.image.DataBufferByte aquireImage();

---

I have no idea where to start on that, the call into EZTwain will get me a dib in c code ....

Then what?