Skip Headers
Oracle® Outside In Image Export Developer's Guide
Release 8.4.0

Part Number E12885-03
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

1 Introduction

Image Export allows an Original Equipment Manufacturer (OEM) to translate almost any document, spreadsheet or presentation into one of several image formats.

Image Export's primary goal is to produce a faithful representation of the source file in a raster image format. There are several raster output format options, including JPEG, TIFF, Windows Bitmap, GIF and PNG. Through a C API, the developer can specify what source file should be exported, set various options that affect the content and structure of the output and specify the name and location of the output file(s) produced.

There may be references to other Outside In Technology SDKs within this manual. To obtain complete documentation for any other Outside In product, see:

http://www.oracle.com/technetwork/indexes/documentation/index.html#middleware

and click on Outside In Technology.

This chapter includes the following sections:

1.1 What's New in Release 8.4.0

1.2 Architectural Overview

The basic architecture of Outside In technologies is the same across all supported platforms:

Filter/Module Description

Input Filter

The input filters form the base of the architecture. Each one reads a specific file format or set of related formats and sends the data to OIT through a standard set of function calls. There are more than 150 of these filters that read more than 500 distinct file formats. Filters are loaded on demand by the data access module.

Export Filter

Architecturally similar to input filters, export filters know how to write out a specific format based on information coming from the chunker module. The export filters generate TIFF, BMP, GIF, JPEG, and PNG.

Chunker

The Chunker module is responsible for caching a certain amount of data from the filter and returning this data to the export filter.

Export

The Export module implements the export API and understands how to load and run individual export filters.

Data Access

The Data Access module implements a generic API for access to files. It understands how to identify and load the correct filter for all the supported file formats. The module delivers to the developer a generic handle to the requested file, which can then be used to run more specialized processes, such as the Export process.


1.3 Definition of Terms

The following terms are used in this documentation.

Term Definition

Developer

Someone integrating this technology into another technology or application. Most likely this is you, the reader.

Source File

The file the developer wishes to export.

Output File

The file being written: TIFF, BMP, GIF, JPEG, and PNG.

Page

A single raster image representation of a page of output . Page sizes will vary depending on the parameters used for an export (maximum size or scaling, etc.) and other options that affect the output type for rendered images.

Data Access Module

The core of Outside In Data Access, in the SCCDA library.

Data Access Submodule (also referred to as "Submodule")

This refers to any of the Outside In Data Access modules, including SCCEX (Export), but excluding SCCDA (Data Access).

Note: Image Export normally comes with only the SCCEX Submodule.

Document Handle (also referred to as "hDoc")

A Document Handle is created when a file is opened using Data Access (see Chapter 4, "Data Access Common Functions"). Each Document Handle may have any number of Subhandles.

Subhandle (also referred to as "hItem")

Any of the handles created by a Submodule's Open function. Every Subhandle has a Document Handle associated with it. For example, the hExport returned by EXOpenExport is a Subhandle. The DASetOption and DAGetOption functions in the Data Access Module may be called with any Subhandle or Document Handle. The DARetrieveDocHandle function returns the Document Handle associated with any Subhandle.


1.4 Directory Structure

Each Outside In product has an sdk directory, under which there is a subdirectory for each platform on which the product ships (for example, ix/sdk/ix_win-x86-32_sdk). Under each of these directories are the following three subdirectories:

In the root platform directory (for example, ix/sdk/ix_win-x86-32_sdk), there are two files:

1.4.1 Installing Multiple SDKs

If you load more than one OIT SDK, you must copy files from the secondary installations into the top-level OIT SDK directory as follows:

  • docs – copy all subdirectories named “[product name]guide” into this directory.

  • redist – copy all binaries into this directory.

  • sdk – this directory has several subdirectories: common, demo, lib, resource, samplecode, samplefiles. In each case, copy all of the files from the secondary installation into the top-level OIT SDK subdirectory of the same name. If the top-level OIT SDK directory lacks any directories found in the directory being copied from, just copy those directories over.

1.5 How to Use Image Export

Here's a step-by-step overview of how to export a source file to an image file.

  1. Call DAIniExt to initialize the Data Access technology. This function needs to be called only once per application. If using threading, then pass in the correct ThreadOption.

  2. Set any options that require a NULL handle type (optional). Certain options need to be set before the desired source file is opened. These options are identified by requiring a NULL handle type. They include, but aren't limited to:

    • SCCOPT_EX_CALLBACKS

    • SCCOPT_EX_UNICODECALLBACKSTR

    • SCCOPT_FALLBACKFORMAT

    • SCCOPT_FIFLAGS

    • SCCOPT_TEMPDIR

    • SCCOPT_UNMAPPABLECHAR

  3. Open the Source File. DAOpenDocument is called to create a document handle that uniquely identifies the source file. This handle may be used in subsequent calls to the EXOpenExport function or the open function of any other Data Access Submodule, and will be used to close the file when access is complete. This allows the file to be accessed from multiple Data Access Submodules without reopening.

  4. Set the Options. If you require option values other than the default settings, call DASetOption to set options. Note that options listed in the Options Guide as having "Handle Types" that accept VTHEXPORT may be set any time before EXRunExport is called. For more information on options and how to set them, see Section 4.8, "DASetOption."

  5. Open a Handle to Image Export. Using the document handle, EXOpenExport is called to obtain an export handle that identifies the file to the specific export product. This handle will be used in all subsequent calls to the specific export functions. The dwOutputId parameter of this function is used to specify that the output file type should be set to one of the following:

    • FI_GIF

    • FI_JPEGFIF

    • FI_JPEG2000

    • FI_PNG

    • FI_BMP

    • FI_TIFF

  6. Make Any Required Calls to Annotation Functions. This is the point at which any calls to annotation functions (such as EXHiliteText, EXInsertText or EXHideText) should be made.

  7. Export the File. EXRunExport is called to generate the output file(s) from the source file.

  8. Close the Handle to Image Export. EXCloseExport is called to terminate the export process for the file. After this function is called, the export handle will no longer be valid, but the document handle may still be used.

  9. Close the Source File. DACloseDocument is called to close the source file. After calling this function, the document handle will no longer be valid.

  10. Close Image Export. DADeInit is called to de-initialize the Data Access technology.

1.6 Copyright Information

The following notice must be included in the documentation, help system, or About box of any software that uses any of Oracle's executable code:

Outside In Image Export © 1991, 2012 Oracle.

The following notice must be included in the documentation of any software that uses Oracle's TIF6 filter (this filter reads TIFF and JPEG formats):

The software is based in part on the work of the Independent JPEG Group.