File ID is part of Oracle's family of OEM products known as Outside In Technology, a powerful document extraction, conversion and viewing technology that can access the information in more than 600 file formats.
Note:
For new functionality information, see What's New guide.There may be references to other Outside In Technology SDKs within this manual. To obtain complete documentation for any other Outside In product, see Middleware documentation page and click Outside In Technology link below.
This chapter includes the following sections:
This chapter explains what Outside In offers.
The Outside In File ID API allows developers to identify files using the same technology that all Outside In products use internally. This specification uses a 16-bit value called the ID or type ID to identify different file formats. These IDs are defined in sccfi.h.
This chapter explains the functionalities used in this API.
This API includes the following functions:
FIIdFile: Returns an ID given a file.
FIIdFileEx: Returns an ID and an ID name given a file.
FIGetFirstId: Returns the first ID in the range of IDs used by this API.
FIGetNextId: Returns the next ID in the range of IDs used by the API.
FIGetIDString: Returns the string associated with a particular FI ID. If no string is available for the specified ID, a value of zero is returned and the pTypeName buffer is not filled.
FIIdSpecial: This function is used to identify whether a file uses special text encodings.
FIIdHandle: This function does the same thing as the IdFile function, except it works on arbitrary open document or sub document handles.
FIDeInit: This function tells the File Identification module that it will not be asked to read additional documents, so it should perform any necessary cleanup tasks. This function should be called at application shutdown time, and only if the module is successfully initialized with a call to FIInit.
FIInit: This function tells the File Identification module to perform any necessary initialization it needs to prepare for document access. This function must be called before the first time the application uses the module to retrieve data from any document.
This chapter explains the SDK directory structure and its subdirectories for each platform.
Each Outside In product has an sdk directory, under which there is a subdirectory for each platform on which the product ships (for example, fi/sdk/fi_win-x86-32_sdk). Each of these directories there are following two subdirectories:
redist: Contains only the files that the customer is allowed to redistribute. These include all the compiled modules, filter support files, .xsd and .dtd files, cmmap000.bin, and third-party libraries like freetype.
sdk: Contains the other subdirectories that used to be at the root-level of an sdk: common, lib (windows only), resource, samplefiles, and samplecode (previously samples). Besides, one new subdirectory Demo. The Demo folder holds all of the compiled sample applications and other files required for the product demo. These are files that the customer should not redistribute (.cfg files, exportmaps, and so forth.).
In the root platform directory (for example, fi/sdk/fi_win-x86-32_sdk), there are two files:
README: Explains the contents of the sdk, and that makedemo must be run in order to use the sample applications.
makedemo (either .bat or .sh – platform-based): This script will either copy (on Windows) or Symlink (on UNIX) the contents of …/redist into …/sdk/demo, so that sample applications can then be run out of the demo directory.