I installed the MacPorts version of Tesseract 4.1.1 on Mojave (macOS v10.14.6) and set up the environment variables to allow running tesseract from the command prompt. I also set the $TESSDATA_PREFIX to "/opt/local/share/tessdata" which is the parent directory of my "traineddata" directory. ( Tesseract installation puts a few other files in the parent directory). I can run tesseract from the command line. I can also have it list the installed traineddata files. So; it and the environment variables are working.
Here is what Tesseract provides in response to the version switch:
$ tesseract --version
tesseract 4.1.1
leptonica-1.80.0
libjpeg 8d (libjpeg-turbo 2.0.6) : libpng 1.6.37 : libtiff 4.2.0 : zlib 1.2.11 : libwebp 1.1.0 : libopenjp2 2.3.1
Found AVX
Found SSE
However; it seems that VietOCR v5.7.2 does not see the environment variables, as it gives a message about, "cannot find Tesseract or Tessdata. Please enter its name in Settings." Furthermore; I can see no option in the settings in which to enter the info per the error message.
The version of Java that I have installed appears to be OK, since I can load images and enlarge/reduce them.
What could be the issue?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I should also note that the installation with MacPorts already created the symbolic link that vectors a request for libtesseract.dylib to /opt/local/lib/libtesseract.4.dylib
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not a Java wizard, but it I do believe that the issue of Apple "tightening" system security is relevant to why the GUI is not working.
On the current O/S Mojave, there is no "/lib" in "/usr/local" and nothing can be added or changed in the "/usr" directory. Apple has prevented access to it. It seems that user-added files now must be placed in the "/opt" directory structure instead. The file libtesseract.4.dylib and the symlink to it, "/opt/local/lib/libtesseract.dylib", are both located in "/opt/local/lib". One can see evidence that other user-installed libraries are also present in that /opt directory structure. I assume that "opt" stands for optional...typical of Apple.
Any ideas how to get around this?
Last edit: Gary Gauthier 2021-01-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
VietOCR uses Tess4J wrapper, which in turn uses JNA library to search and load native libraries. The program is looking for a libtesseract.dylib, which you have but may not be in the paths that it looks for.
But there's a workaround. You can specify the paths JNA is searching for the native libraries by setting a property at the command line. So please open a terminal and try with this command option:
That worked. Thank you so much, Quan!
Just need to get scanning and spell-checking working.
I thought scanning was built-in, but seems there must be something missing.
As for spell-checking, I need to find the components I need to install.
Is there anything that covers those two issues?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quan;
I'm still working on getting the scanning functioning. Installing SANE on a Mac for my Epson scanner is a bit dfficult. I've contacted the author for help.
I wasn't able to use the instructions on the noted page for "hunspell"., since I use MacPorts.
I installed hunspell 1.70 and the dictionaries, plus checked that hunspell could list them using the "-D" option at the command prompt. That worked.
Then I went to VietOCR and tried to initiate a spell-check. It returned the error, "Spellcheck initialization error!". I really don't know what VietOCR was trying to do, so am not sure how to proceed. I suspect that it couldn't initiate ite for some reason.
Here is a bit of the error stream which may help you in determining what VietOCR was trying to find:
java.lang.Exception: Spellcheck initialization error!
at net.sourceforge.vietpad.utilities.SpellCheckHelper.enableSpellCheck(Unknown Source)
at net.sourceforge.vietocr.GuiWithSpellcheck.jToggleButtonSpellCheckActionPerformed(Unknown Source)
at net.sourceforge.vietocr.Gui$42.actionPerformed(Unknown Source)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. A bit of headway. I noticed that the hunspell 1.70 installed libhunspell-1.7.a in /opt/local/lib. So, I made a symbolic link called libhunspell.a that pointed to it. However; I still getting the same error, as if VietOCR doesn't find it and needs a commandline switch.
By the way the MacPort version of hunspell was packaged as hunspell-1.7.0_1.darwin_18.x86_64.tbz2, which impies that it was made for the mac and 64-bit operation. Is that the issue?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quan;
I got rid of the previously noted symlink and created a libhunspell.dylib one that links to libhunspell-1.7.0.dylib in the same /opt/local/lib directory. Unfortunately it still doesn't seem to find it. Perhaps VietOCR doesn't know to look for the libhunspell.dylib in /opt/local/lib? I'm not sure how Java knows where to look. Should "/opt/local/lib" be added to the profile?
Actually; I did a bit or digging and found that I've already told VietOCR to look in the "/opt/local/lib/" directory, because I invoke it with "java -Djna.library.path=/opt/local/lib/ -Xms128m -Xmx2048m -jar /Applications/VietOCR3/VietOCR.jar". So it really should be finding the symlink and invoking the correct .dylib file.
Last edit: Gary Gauthier 2021-01-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. I found that since I have LibreOffice/NeoOffice installed (which uses hunspell), the dynamic hunspell library was already in the /usr/lib directory. So I created a symlink (libhunspell.dylib) in the /opt/local/lib directory that points to /usr/lib/libhunspell-1.2.0.0.0.dylib That should work, since the symlink is on the specified library path when starting VietOCR.
Because LibreOffice/NeoOffice installed, the dictionaries are in both the VietOCR/dict directory as well as in /Users/[user-name]/Library/Spelling Not sure if that is an issue for VietOCR, but my LibreOffice/NeoOffice spell-checking still works fine.
Unfortunately; VietOCR now gives a "Spellcheck initialization error!"
[Are there other hunspell-related dependencies that I need to examine? Perhaps the dictionary files from VietOCR are not in the correct format for a Mac and it's not seeing the ones from LibreOffice/NeoOffice? Would copying the dictionary files from LibreOffice/NeoOffice to the VietOCR directory be something to try?]
It's not all gloomy... I tried VietOCR on some rather poor images of typewritten World War 1 war-diaries and got well over 90% of it correct with nothing more than deskewing the images! If you'd seen the originals, you'd say it was amazing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The integrated JNA Hunspell wrapper works with Hunspell 1.7 -- it was verified working on Windows and Linux Ubuntu 20.10. Your version seems too old, and probably is not compatible. I wonder why the Hunspell version bundled with LibreOffice is so outdated. Is it because of outdated LibreOffice itself?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I put things back to invoking the dylib labelled v1.7, but when I ran the hunspell executable to check the correct version was running it came up with;
Sounds like Macports doesn't actually install a true version 1.7.
Could you tell me what your system says in response to the "hunspell -v" command?
I may have to re-install hunspell.
Last edit: Gary Gauthier 2021-01-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That seems to indicate that its throwing an exception because it can't find the user dictionaries in the VietOCR "dict/" directory, not because of an error in running hunspell. However; the dictionaries are in the correct VietOCR directory. That means that perhaps VietOCR can't establish its "baseDir". I'm not sure of the details of how it does that. Perhaps VietOCR needs to be in the PATH or in a particular directory on a Mac?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No problem. We can try to get it to work. After browsing the source again, it turns out that the current JNA Hunspell wrapper is actually looking for the native library with a different name than we expected.
It looks like those names might be obsolete. I've just updated it to search for libhunspell.dylib to match the symlink on your systemj. Please try out (see attachment) and see if Hunspell could get loaded.
Thanks,
Quan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This version gets further, but seems to have an issue. I've verified that 'libhunspell.dylib' is present as a symlink in '/opt/local/lib' and points to '/opt/local/lib/libhunspell-1.7.0.dylib'. I've checked that that 'hunspell' itself works from the command line.
So I'm not quite sure what to make of the following console message. Is this due to VietOCR expecting hunspell to be 32-bit and finding a 64-bit library? (If so, this could also be the same issue that is haunting the scanner extension. Many ports these days automatically compile for 64-bit, as that is the direction that the O'S's are going.)
Lastlogin: WedJan2706:19:47onttys000/Users/garygauthier/VietOCR3/VietOCR.sh; exit;Garys-MacBook-Pro:~garygauthier$ /Users/garygauthier/VietOCR3/VietOCR.sh; exit;Warning: Invalidresolution0dpi. Using70instead.
Estimatingresolutionas246Exceptioninthread"AWT-EventQueue-0"java.lang.UnsatisfiedLinkError: Can't find libhunspell.dylib in the filesystem nor in the classpathjava.lang.UnsatisfiedLinkError: Unabletoloadlibrary'hunspell':
dlopen(/opt/local/lib/libhunspell.dylib, 9): nosuitableimagefound. Didfind:
/opt/local/lib/libhunspell.dylib: filetooshort/opt/local/lib/libhunspell.dylib: filetooshortdlopen(/opt/local/lib/libhunspell.dylib, 9): nosuitableimagefound. Didfind:
/opt/local/lib/libhunspell.dylib: filetooshort/opt/local/lib/libhunspell.dylib: filetooshortdlopen(/Users/garygauthier/Library/Frameworks/hunspell.framework/hunspell, 9): imagenotfounddlopen(/Library/Frameworks/hunspell.framework/hunspell, 9): imagenotfounddlopen(/System/Library/Frameworks/hunspell.framework/hunspell, 9): imagenotfoundNativelibrary(darwin/libhunspell.dylib)notfoundinresourcepath([file:/Users/garygauthier/VietOCR3/VietOCR.jar])atcom.stibocatalog.hunspell.Hunspell.<init>(UnknownSource)atcom.stibocatalog.hunspell.Hunspell.getInstance(UnknownSource)atcom.stibocatalog.hunspell.Hunspell.getInstance(UnknownSource)atnet.sourceforge.vietpad.utilities.SpellCheckHelper.initializeSpellCheck(UnknownSource)atnet.sourceforge.vietpad.utilities.SpellCheckHelper.enableSpellCheck(UnknownSource)atnet.sourceforge.vietocr.GuiWithSpellcheck.jToggleButtonSpellCheckActionPerformed(UnknownSource)atnet.sourceforge.vietocr.Gui$42.actionPerformed(UnknownSource)atjavax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)atjavax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)atjavax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)atjavax.swing.JToggleButton$ToggleButtonModel.setPressed(JToggleButton.java:308)atjavax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)atjava.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289)atjava.awt.Component.processMouseEvent(Component.java:6539)atjavax.swing.JComponent.processMouseEvent(JComponent.java:3324)atjava.awt.Component.processEvent(Component.java:6304)atjava.awt.Container.processEvent(Container.java:2239)atjava.awt.Component.dispatchEventImpl(Component.java:4889)atjava.awt.Container.dispatchEventImpl(Container.java:2297)atjava.awt.Component.dispatchEvent(Component.java:4711)atjava.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)atjava.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)atjava.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)atjava.awt.Container.dispatchEventImpl(Container.java:2283)atjava.awt.Window.dispatchEventImpl(Window.java:2746)atjava.awt.Component.dispatchEvent(Component.java:4711)atjava.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)atjava.awt.EventQueue.access$500(EventQueue.java:97)atjava.awt.EventQueue$3.run(EventQueue.java:709)atjava.awt.EventQueue$3.run(EventQueue.java:703)atjava.security.AccessController.doPrivileged(NativeMethod)atjava.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)atjava.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)atjava.awt.EventQueue$4.run(EventQueue.java:733)atjava.awt.EventQueue$4.run(EventQueue.java:731)atjava.security.AccessController.doPrivileged(NativeMethod)atjava.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)atjava.awt.EventQueue.dispatchEvent(EventQueue.java:730)atjava.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)atjava.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)atjava.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)atjava.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)atjava.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)atjava.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Last edit: Gary Gauthier 2021-01-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Web searching for "/opt/local/lib/libhunspell.dylib: file too short" and the general concensus was the symbolic link might get corrupted. You may want to delete and recreate it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That worked perfectly and I can now correct errors in the OCR'd text.
There's only one function left for me to debug and get working.
Could I ask if the scan function requires 32-bit or will it run with a 64-bit SANE install?
Of course; I'll also check the symlinks to make sure they're OK as well.
Last edit: Gary Gauthier 2021-01-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Re: Scanning functionality
The SAN packages were installed from precompiled binaries (http://www.ellert.se/twain-sane/) supplied by Mattias Ellert. So it gets istalled in the regular usr directory structure. I decided to use his installation package, as it has a preference pane configuration applet, which leaves less room for error.
I'm getting the following NullPointerException. Not sure what the isuue might be. Any ideas for me to follow up?
A bit more info about the SANE installation on a Mac. The 'scanimage', 'sane-find-scanner' and 'sane-config' executables are installed in '/usr/local/bin' by Mattias' install packages. The directory '/usr/local/bin' is in the PATH.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I installed the MacPorts version of Tesseract 4.1.1 on Mojave (macOS v10.14.6) and set up the environment variables to allow running tesseract from the command prompt. I also set the $TESSDATA_PREFIX to "/opt/local/share/tessdata" which is the parent directory of my "traineddata" directory. ( Tesseract installation puts a few other files in the parent directory). I can run tesseract from the command line. I can also have it list the installed traineddata files. So; it and the environment variables are working.
Here is what Tesseract provides in response to the version switch:
$ tesseract --version
tesseract 4.1.1
leptonica-1.80.0
libjpeg 8d (libjpeg-turbo 2.0.6) : libpng 1.6.37 : libtiff 4.2.0 : zlib 1.2.11 : libwebp 1.1.0 : libopenjp2 2.3.1
Found AVX
Found SSE
However; it seems that VietOCR v5.7.2 does not see the environment variables, as it gives a message about, "cannot find Tesseract or Tessdata. Please enter its name in Settings." Furthermore; I can see no option in the settings in which to enter the info per the error message.
The version of Java that I have installed appears to be OK, since I can load images and enlarge/reduce them.
What could be the issue?
I should also note that the installation with MacPorts already created the symbolic link that vectors a request for libtesseract.dylib to /opt/local/lib/libtesseract.4.dylib
Hi Gary,
Can you check Issue 194 to see if it helps?
Thanks,
Quan
Hi Quan;
I'm not a Java wizard, but it I do believe that the issue of Apple "tightening" system security is relevant to why the GUI is not working.
On the current O/S Mojave, there is no "/lib" in "/usr/local" and nothing can be added or changed in the "/usr" directory. Apple has prevented access to it. It seems that user-added files now must be placed in the "/opt" directory structure instead. The file libtesseract.4.dylib and the symlink to it, "/opt/local/lib/libtesseract.dylib", are both located in "/opt/local/lib". One can see evidence that other user-installed libraries are also present in that /opt directory structure. I assume that "opt" stands for optional...typical of Apple.
Any ideas how to get around this?
Last edit: Gary Gauthier 2021-01-24
VietOCR uses Tess4J wrapper, which in turn uses JNA library to search and load native libraries. The program is looking for a
libtesseract.dylib, which you have but may not be in the paths that it looks for.But there's a workaround. You can specify the paths JNA is searching for the native libraries by setting a property at the command line. So please open a terminal and try with this command option:
java -Djna.library.path=/opt/local/lib/ -jar VietOCR.jaror
java -Djna.library.path=/opt/local/lib/ -Xms128m -Xmx2048m -jar VietOCR.jarif you want to provide more RAM to the program.
Last edit: Quan Nguyen 2021-01-24
That worked. Thank you so much, Quan!
Just need to get scanning and spell-checking working.
I thought scanning was built-in, but seems there must be something missing.
As for spell-checking, I need to find the components I need to install.
Is there anything that covers those two issues?
For spellcheck, you'd need to install Hunspell.
http://pankdm.github.io/hunspell.html
For scanning, only Windows and Linux 32-bit are supported. If someone can develop a solution for MacOS....
Quan;
I'm still working on getting the scanning functioning. Installing SANE on a Mac for my Epson scanner is a bit dfficult. I've contacted the author for help.
I wasn't able to use the instructions on the noted page for "hunspell"., since I use MacPorts.
I installed hunspell 1.70 and the dictionaries, plus checked that hunspell could list them using the "-D" option at the command prompt. That worked.
Then I went to VietOCR and tried to initiate a spell-check. It returned the error, "Spellcheck initialization error!". I really don't know what VietOCR was trying to do, so am not sure how to proceed. I suspect that it couldn't initiate ite for some reason.
Here is a bit of the error stream which may help you in determining what VietOCR was trying to find:
java.lang.Exception: Spellcheck initialization error!
at net.sourceforge.vietpad.utilities.SpellCheckHelper.enableSpellCheck(Unknown Source)
at net.sourceforge.vietocr.GuiWithSpellcheck.jToggleButtonSpellCheckActionPerformed(Unknown Source)
at net.sourceforge.vietocr.Gui$42.actionPerformed(Unknown Source)
Ok. A bit of headway. I noticed that the hunspell 1.70 installed libhunspell-1.7.a in /opt/local/lib. So, I made a symbolic link called libhunspell.a that pointed to it. However; I still getting the same error, as if VietOCR doesn't find it and needs a commandline switch.
By the way the MacPort version of hunspell was packaged as hunspell-1.7.0_1.darwin_18.x86_64.tbz2, which impies that it was made for the mac and 64-bit operation. Is that the issue?
JNA is looking for
.dylibon MacOS. You may want to try a symbolic link with that extension.Quan;
I got rid of the previously noted symlink and created a libhunspell.dylib one that links to libhunspell-1.7.0.dylib in the same /opt/local/lib directory. Unfortunately it still doesn't seem to find it. Perhaps VietOCR doesn't know to look for the libhunspell.dylib in /opt/local/lib? I'm not sure how Java knows where to look. Should "/opt/local/lib" be added to the profile?
My .profile file is currently set as:
Actually; I did a bit or digging and found that I've already told VietOCR to look in the "/opt/local/lib/" directory, because I invoke it with "java -Djna.library.path=/opt/local/lib/ -Xms128m -Xmx2048m -jar /Applications/VietOCR3/VietOCR.jar". So it really should be finding the symlink and invoking the correct .dylib file.
Last edit: Gary Gauthier 2021-01-25
.ais static library. JNA requires dynamic library.dylibversion. You may have to build Hunspell from the source.Hi Quan;
Ok. I found that since I have LibreOffice/NeoOffice installed (which uses hunspell), the dynamic hunspell library was already in the /usr/lib directory. So I created a symlink (libhunspell.dylib) in the /opt/local/lib directory that points to /usr/lib/libhunspell-1.2.0.0.0.dylib That should work, since the symlink is on the specified library path when starting VietOCR.
Because LibreOffice/NeoOffice installed, the dictionaries are in both the VietOCR/dict directory as well as in /Users/[user-name]/Library/Spelling Not sure if that is an issue for VietOCR, but my LibreOffice/NeoOffice spell-checking still works fine.
Unfortunately; VietOCR now gives a "Spellcheck initialization error!"
[Are there other hunspell-related dependencies that I need to examine? Perhaps the dictionary files from VietOCR are not in the correct format for a Mac and it's not seeing the ones from LibreOffice/NeoOffice? Would copying the dictionary files from LibreOffice/NeoOffice to the VietOCR directory be something to try?]
It's not all gloomy... I tried VietOCR on some rather poor images of typewritten World War 1 war-diaries and got well over 90% of it correct with nothing more than deskewing the images! If you'd seen the originals, you'd say it was amazing.
Hi Gary,
The integrated JNA Hunspell wrapper works with Hunspell 1.7 -- it was verified working on Windows and Linux Ubuntu 20.10. Your version seems too old, and probably is not compatible. I wonder why the Hunspell version bundled with LibreOffice is so outdated. Is it because of outdated LibreOffice itself?
Quan;
I put things back to invoking the dylib labelled v1.7, but when I ran the hunspell executable to check the correct version was running it came up with;
Sounds like Macports doesn't actually install a true version 1.7.
Could you tell me what your system says in response to the "hunspell -v" command?
I may have to re-install hunspell.
Last edit: Gary Gauthier 2021-01-26
Sorry to bother you further Quan.
I thought to have a look at the nature of the spellcheck error that came up in the console window.
It looks as the exception is triggered by this code:
That seems to indicate that its throwing an exception because it can't find the user dictionaries in the VietOCR "dict/" directory, not because of an error in running hunspell. However; the dictionaries are in the correct VietOCR directory. That means that perhaps VietOCR can't establish its "baseDir". I'm not sure of the details of how it does that. Perhaps VietOCR needs to be in the PATH or in a particular directory on a Mac?
Hi Gary,
No problem. We can try to get it to work. After browsing the source again, it turns out that the current JNA Hunspell wrapper is actually looking for the native library with a different name than we expected.
https://github.com/nguyenq/VietOCR3/blob/master/src/com/stibocatalog/hunspell/Hunspell.java
https://github.com/dren-dk/HunspellJNA/blob/master/src/dk/dren/hunspell/Hunspell.java
It looks like those names might be obsolete. I've just updated it to search for
libhunspell.dylibto match the symlink on your systemj. Please try out (see attachment) and see if Hunspell could get loaded.Thanks,
Quan
Thanks for following up on this. I just ran the new test-version, but got a different exception.
Looks like it got further though.
Not sure, but there could be a simple typo in the target library name in the code. Here is the console window output.
Sorry, incorrect libname. Please try this version.
Quan;
This version gets further, but seems to have an issue. I've verified that 'libhunspell.dylib' is present as a symlink in '/opt/local/lib' and points to '/opt/local/lib/libhunspell-1.7.0.dylib'. I've checked that that 'hunspell' itself works from the command line.
So I'm not quite sure what to make of the following console message. Is this due to VietOCR expecting hunspell to be 32-bit and finding a 64-bit library? (If so, this could also be the same issue that is haunting the scanner extension. Many ports these days automatically compile for 64-bit, as that is the direction that the O'S's are going.)
Last edit: Gary Gauthier 2021-01-27
Web searching for "/opt/local/lib/libhunspell.dylib: file too short" and the general concensus was the symbolic link might get corrupted. You may want to delete and recreate it.
SUCCESS!!!!
That worked perfectly and I can now correct errors in the OCR'd text.
There's only one function left for me to debug and get working.
Could I ask if the scan function requires 32-bit or will it run with a 64-bit SANE install?
Of course; I'll also check the symlinks to make sure they're OK as well.
Last edit: Gary Gauthier 2021-01-27
Quan;
Re: Scanning functionality
The SAN packages were installed from precompiled binaries (http://www.ellert.se/twain-sane/) supplied by Mattias Ellert. So it gets istalled in the regular usr directory structure. I decided to use his installation package, as it has a preference pane configuration applet, which leaves less room for error.
I'm getting the following NullPointerException. Not sure what the isuue might be. Any ideas for me to follow up?
Quan;
A bit more info about the SANE installation on a Mac. The 'scanimage', 'sane-find-scanner' and 'sane-config' executables are installed in '/usr/local/bin' by Mattias' install packages. The directory '/usr/local/bin' is in the PATH.