HTML Export's primary goal is producing faithful representations of source files using the HTML, GIF, JPEG and PNG formats. Using a C, Java or .NET API, the developer can set various options that affect the content and structure of the output.
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:
The updated list of supported formats is linked from the page http://www.outsideinsdk.com/. Look for the data sheet with the latest supported formats.
The following new formats are supported:
Microsoft Word 2016
Microsoft Excel 2016
Microsoft PowerPoint 2016
MS Outlook 2011 for Mac (OLM and EML)
Corel WordPerfect X7
Corel Quattro Pro X7
Corel Presentations X7
Corel Draw X7
iWork KeyNote (text only)
AutoCAD 2015
The following new options are introduced:
A new option, SCCOPT_PDF_FILTER_MAX_EMBEDDED_OBJECTS, is added that allows you to limit the number of embedded objects produced in PDF files.
A new option, SCCOPT_PDF_FILTER_MAX_VECTOR_PATHS, is added that allows you to limit the number of vector paths produced in PDF files.
A new option, SCCOPT_PDF_FILTER_WORD_DELIM_FRACTION, is added. This allows you to control the spacing threshold in PDF input documents.
Support for the following general accuracy and fidelity features is provided:
MS Word table styles supported
MS Office Chart data label styles extended
Font selection algorithm improvements implemented
Outlook MSG “best body” algorithm implemented
PPTX Master slide Transparency provided
Four Color (CMYK) progressive JPEG supported
Processing of very large spreadsheets containing large areas of white space are optimized for improved performance supported
The following Operating System support is provided:
Windows 10
SLES 12
The following .NET API changes are implemented:
A new configuration object — OutsideInConfig
Get method for options
Redirected IO for temp files
The following Java API changes are implemented:
Get method for options
Redirected IO for temp files
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 600 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 HTML, 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. |
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: HTML, CSS, JavaScript, GIF, JPEG, and PNG. |
Page |
A single text and its associated graphics to make a page of output. Pages have suggested lengths, but the actual length may be greater or smaller than the suggested value. Page sizes count only the bytes of visible text in the document, not markup. |
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: HTML Export normally comes with only the SCCEX Submodule. |
Document Handle (also referred to as " |
A Document Handle is created when a file is opened using Data Access (see Data Access Common Functions). Each Document Handle may have any number of Subhandles. |
Subhandle (also referred to as " |
Any of the handles created by a Submodule's |
Each Outside In product has an sdk directory, under which there is a subdirectory for each platform on which the product ships (for example, hx/sdk/hx_win-x86-32_sdk). Under each of these directories are the following three 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). In addition, one new subdirectory has been added, demo, that holds all of the compiled sample apps and other files that are needed to demo the products. These are files that the customer should not redistribute (.cfg files, exportmaps, etc.).
In the root platform directory (for example, hx/sdk/hx_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.
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:
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.