1 Introduction
Outside In Web View Export is an SDK that enables an application to produce high quality, web-compatible renditions of documents created by standard business software. When asked to render a document, Outside In Web View Export produces HTML, CSS, and Javascript files which, when displayed in a browser, provide a high fidelity, interactive, and customizable user experience.
There may be references to other Oracle Outside In Technology SDKs within this manual. To obtain complete documentation for any other Oracle 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 this Release
-
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.
1.2 Web View Export Overview
The following sections provide an overview of the Web View Export SDK:
1.2.1 Browser Compatibility
The output produced by the Web View Export SDK takes advantage of the current state-of-the-art browsers and the capabilities of HTML5, sometimes including Javascript or HTML5-specific features such as a drawing canvas, web fonts, or SVG elements. Therefore, the use of an HTML5-capable browser is assumed and required.
1.2.2 Architecture
The architecture of Outside In Web View Export consists of two major components:
-
An export module (EXH5) with a robust API similar to other Outside In export products, which produces high-quality renditions of input documents.
-
A Javascript library (OIT.JS) used by the output HTML files, which provides interactive functions and provides a browser-side API of its own that allows web developers to customize and extend the capabilities of the web view of a document.
In a typical deployment, the export module would be used on a server to create the Web View Export output. The output files, along with the Javascript library, would then be made available by a web server to users who are accessing the output from their browsers.
Export Module
The export module is a loadable library with a rich API for controlling its behavior and certain aspects of the output. Versions of the API are available for C, Java, and .NET programs.
Detailed reference documentation for the API can be found at the following locations:
-
[Link for C Reference Manual]
-
[Link for Java Reference Manual]
-
[Link for .NET Reference Manual]
Web View Export Javascript Library
The Web View Export browser-side API consists of a global object that provides a set of functions that allow a script writer to customize the navigation and interactive behavior of the Web View Export output. Outside In Web View Export allows custom scripts to be referenced from within the HTML5 renditions, which enables use of the browser-side API and integration into a web application.
1.2.3 Web View Export Output
For each exported document, Web View Export will produce at least one HTML file, one data file in either Javascript or JSON format (depending on which output structure option is selected), and one CSS file. Depending on configuration settings and the contents of the input document, Web View Export may also produce PNG image files, TTF font files, plain text files, and additional HTML and/or JSON files.
Customizing the Web View Export Output
See Appendix 10, "Web View Export Options" for the C API of the Web View Export Module.
The descriptions below are intended to add context to some of the new options that have been added specifically for the Web View Export product.
Partitioning of Content Between Output Files (Output Paging)
It is likely that an application would not want to render large documents as a single HTML output file. The Web View Export export module provides an ”output paging” option that allows a document be rendered to separate HTML files for each page, allowing for faster random access in a browser.
-
C SDK: SCCOPT_OUTPUT_STRUCTURE
-
Java API:
-
.NET API:
Extending Output with Custom Scripts
The export module can insert links to one or more custom scripts into the Web View Export output. This enables a custom script to interact in the browser with the Web View Export Javascript API, and allows a script to customize the ways in which the user interacts with the document.
Because the order in which scripts are loaded is significant, Web View Export allows complete control over the ordering of all script links in the output HTML. One option is provided for inserting scripts above the link to the Outside In Javascript library (oit.js), and another option is provided for inserting scripts after oit.js. If multiple scripts are linked, they will appear in the output file in the order they were specified to the export module.
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 output file being written. |
|
Data Access Module |
The core of Oracle Outside In Data Access, in the SCCDA library. |
|
Data Access Submodule (also referred to as "Submodule") |
This refers to any of the Oracle Outside In Data Access modules, including SCCEX (Export), but excluding SCCDA (Data Access). |
|
Document Handle (also referred to as "hDoc") |
A Document Handle is created when a file is opened using Data Access (see Chapter 6, "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 Oracle Outside In product has an sdk directory, under which there is a subdirectory for each platform on which the product ships. Under each of these directories are the following three subdirectories:
-
docs: Contains both a PDF and HTML version of the product manual.
-
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.
-
sdk: Contains the materials necessary to develop software that uses the Web View Export export module, as well as demonstration code for instructional purposes.
In the root directory of the SDK deliverable, 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.
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.
