RecAPI
|
OmniPage CSDK v21.1 has introduced Java API to access KernelAPI, RecAPIPlus and RecPDF functions in Java. The mapping code is autogenerated by SWIG reflecting our C API, and using JNI (Java Native Interface). This autogenerated behaviour, and the functions offered in Java try to reflect exactly the same functions with mostly same parameters. See JavaSamples bundled with this CSDK to see the example usages.
Installation
Java API does not require any extra step after a normal install of CSDK. Instead, the user has to locate omnipage_csdk.jar inside a CSDK installation "bin" folder and include it in the java classpath.
Samples
After installing the CSDK, Java samples are available here:
For a 32-bit CSDK install, please replace x64 by x86 everywhere in this Java section.
To use the prepared .cmd files in this directory (build.cmd and run.cmd), user has to set JAVA_HOME environment variable properly (e.g. "C:\Program Files\Java\jdk1.8.0_77").
These .cmd files are are very simple 1-liner texts, so you should definitely open and examine them later - everything possible to be run without setting JAVA_HOME then.
In order to build JavaSample, open a dos prompt or powershell in the directory above, and issue build.cmd.
It compiles java files under:
Now you can run it:
Note: color codes are being used by JavaSamples for dos prompt. In case you are not seeing the colors, then you need to open registry, and create in HKCU\Console a DWORD named VirtualTerminalLevel and set it to 0x1.
Initialization
The function LoadJNI() tries to load csdk_omnipage.dll from the same directory as csdk_omnipage.jar.
It also has a version with a parameter, allowing to find the dll using a relative path to this jar file :
In case of a repackaged installation for a 3rd party use would put CSDK binaries in various folders, the csdk_omnipage.dll has to be loaded manually:
In this case, user has to provide the absolute file path to csdk_omnipage.dll by Java code.
Further necessary omnipage dlls are loaded on demand automatically from exactly the same directory of the already loaded csdk_omnipage.dll.
User has to guarantee that csdk_omnipage.jar and csdk_omnipage.dll are from exactly the same CSDK version when dislocating them.
The csdk_omnipage.dll will look for other necessary DLLs exactly in the same folder where it was loaded from, but only after any of a later kRecInit / RecInitPlus / rPdfInit calls.
Starting from CSDK version 22.0, the extension of PATH variable is not required.
After this necessary runtime step, you can instantiate the main class encapsulating the CSDK API and then use it afterward:
After acquiring the above RecAPI instance, your first real omnipage CSDK call should be any of kRecInit, RecInitPlus and rPdfInit - depending on which functions you are using, according to kRec/Rec/rPdf function name prefixes.
It is important to call the belonging kRecQuit/RecQuitPlus/rPdfQuit for freeing resources in the end, exactly once for these 3 types of Init calls, in reverse order as usual.
Types
It is assumed that your Java IDE shows type information in-depth, and you as a user of this Java API just have to chose from the public symbols being offered.
The returning agruments of basic types are problemmatic in Java - here it is solved via array of 1 size of that basic type.
E.g. Sample001.java:
For structs, member values are accessible via the usual setter/getter functions fashion in Java: naming convention is set/get prefix + struct member name. The only exceptions are a few common structs: RECT, SIZE and POINT where helper constructors added by us to avoid excessive use of setters/getters (position of arguments are matching with struct members order).
Enums: here we map safe type of enums (its int value is unused), and unsafe. For the latter one, you want the integer representation in C API (see headers) - to acccess that value, please use the toInt() member function.
Special types that implement java.lang.AutoCloseable:
OutputByteBuffer (Sample007.java)
ProgressMonitorCallback (Sample048.java)
The recommendation of effectively using AutoCloseable (as seen in JavaSamples) causes to avoid running the garbage collector too early.
For the usage of arrays, please look for the given function in JavaSamples as there can be minor differences in how they can be acquired and used.
Resource handling
Where not mentioned explicitly (and no belonging C API function) in this document, objects are freed automatically. E.g. the kRecFree function is available only in C, but doesn't exist in Java, so no need to care about it. However, there are a few ones that exist on the Java API too, and the user has to call these explicitly:
It is important to call these functions before kRecQuit/RecQuitPlus/rPdfQuit, in case have any handle unfreed.
Limitations
These functions are not supported in Java at this moment: