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:
The following sections provide an overview of the Web View Export SDK:
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.
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:
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.
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. In addition to the files that represent the content from the source document, each set of output files will include a manifest file in JSON format, which includes data about the export operation itself. Depending on configuration settings and the contents of the input document, Web View Export may also produce PNG image files, WOFF font files, plain text files, and additional HTML and/or JSON files.
WOFF Font
OIT now supports WOFF fonts. Web View Export displays fonts as output files when the "font reference method" is configured as Export.
Prior to this release, the output was displayed in TTF font. From 8.5.4, the output is displayed in the WOFF font, thereby not supporting the TTF fonts.
Fill a directory with WOFF fonts and specify it as the font directory during export.
Make the same set of fonts available on the web server that will be hosting the exported output.
Set the font reference method to "base URL" and set the font base URL to the web location of the fonts used during export.
Customizing the Web View Export Output
See Web View Export C/C++ 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: WebViewOutputStructure
.NET API: WebViewStructure
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.
Export Manifest File
For all variations of the output structure, Web View Export will produce a single JSON file containing data describing the output produced during the export process. It also may contain information about the fonts that were used in the input document.
Manifest files are created at the end of the export process, so they are not available during streaming for AJAX_STREAMING and PAGE_STREAMING output structures.
The manifest file is named using the primary output file name and the suffix ".manifest.json":
[name].manifest.json
For example, if the primary output file name is "output.html", the css file would be named "output.manifest.json"
The manifest file contains a top level JSON object with three properties: pages, requestedFonts, and files. The values of these properties are described below.
pagesThe pages array contains a list of the pages in the document, in order by page number (so the first element in this array corresponds to page 1, the second to page 2 and so on). This array consists of objects with the following properties:
Table 1-1 Lists the properties-Pages Array
| Property | Type | Description |
|---|---|---|
|
section |
Number |
The 0-based index of the section containing the page. |
|
type |
String |
The page type, as defined in its original document. |
|
name |
String |
The page or sheet name, if provided in the input file. |
|
w |
String |
The page width as a CSS length value, if applicable. |
|
h |
String |
The page height as a CSS length value, if applicable. |
|
dpi |
Number |
The DPI for the page, if applicable. |
The page type will be one of the following:
page: Word processor page
worksheet: Spreadsheet worksheet
database: Database table
bitmap: Bitmap image
archive: File archive
drawing: Vector drawing
slide: Presentation slide
html: HTML page
chart: Spreadsheet chart
emailarchive: Email archive
email: Email document
The requestedFonts array contains objects that specify which fonts were referenced as the file was being rendered. Each object in this array will have the following properties:
Table 1-2 RequestedFonts array
| Property | Type | Description |
|---|---|---|
|
name |
String |
The font name, e.g. "Times New Roman" |
|
embedded |
Boolean |
If this property is absent, |
The files object has a set of properties corresponding to the categories of output file that were produced during export. The file categories are as follows:
page: The content files for each page of the document
data: Data files, such as spreadsheet or database data
text: Raw text files
content: Document content files for information such as document metadata and document structure
style: CSS files
image: Bitmap images
font: Exported fonts
aux: Auxiliary files such as fill pattern bitmaps
The value of each property is an array containing information about the files that were produced. Each object in these arrays will have the following properties:
Table 1-3 Object in the array
| Property | Type | Description |
|---|---|---|
|
url |
String |
The file url |
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 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. |
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 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.
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.
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.