1 Introduction
This chapter is an introduction to the Oracle Outside In Viewer module. The Viewer is a part of Oracle's Outside In family of OEM technologies, a powerful document viewing and conversion technology that can access the information in more than 600 file formats.
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.
Note:
For new functionality information, see What's New guide.This chapter includes the following sections:
1.1 What Does the Oracle Outside In Viewer Do?
For each supported platform, the Oracle Outside In Viewer provides a way to create a rectangular view consisting of a horizontal scroll bar, a vertical scroll bar and a display area. This rectangle is referred to as the view window.
Figure 1-1 View Window
![Graphic showing view window with blank display Graphic showing view window with blank display](img/viewwindow.gif)
The view window is blank until the developer sends a SCCVW_VIEWFILE message. This message allows the developer to specify a file to be viewed. On some platforms you can specify a bitmap to display when no file is being viewed.
If SCCVW_VIEWFILE returns successfully, the display area will contain the top part of the file specified and scroll bars will be enabled, allowing the user to move around the rest of the file.
Figure 1-2 View Window in Use
![Graphic of an aquarium in the view window Graphic of an aquarium in the view window](img/viewwindo_plusimage.gif)
Once a file is being viewed, a whole set of messages can be sent by the developer to the view window allowing the developer to print, copy, search, change the look of, and perform a number of other operations on the view.
Eventually, the developer will either close the file (SCCVW_CLOSE) and destroy the view window or make another call to SCCVW_VIEWFILE.
1.2 Architectural Overview
The basic architecture of the Oracle Outside In Viewer is noted below. There are no supported platform distinctions:
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 the chunker module 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. |
Chunker |
The Chunker module is responsible for caching a certain amount of data from the filter and returning this data as a display engine. It is also responsible for running the filter to rebuild any data not already in the cache that is requested. |
Display Engine |
The Display Engine is responsible for reading data from the chunker and displaying it in the view window. It is also responsible for all user interface, clipboard and printing for a given data type. There are currently six display engines: Document, Spreadsheet/Database, Bitmap, Drawing, Archive and Hex. Display Engines are loaded on demand by the view window. |
View Window |
The View Window controls all of the modules for this product. |
1.3 Definition of Terms
Term | Definition |
---|---|
Developer |
Someone integrating this technology into another technology or application. Most likelythis is you, the reader. |
Source File |
The file the developer wishes to view. |
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 (for example, vw/sdk/vw_win-x86-32_sdk). 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, like freetype.
-
sdk: Contains the other subdirectories that used to be at the root-level of an sdk (common, lib, 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, vw/sdk/vw_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 (.bat platform-based): This script will copy (on Windows) the contents of …/redist into …/sdk/demo, so that sample applications can then be run out of the demo directory.