The UNIX implementation of the Export product set is delivered as a set of shared libraries.
These products are supported on the following platforms:
Platform and Version | HTML Export | Image Export | PDF Export | Search Export | XML Export |
---|---|---|---|---|---|
HP-UX (RISC 32), 11.0 and 11i (v1.5, v1.6) | X | X | X | X | |
HP-UX (PA - RISC 64), 11i v3 (11.31) | X | X | X | ||
HP-UX (Itanium 64) 11i (v1.5, v1.6), 11i v2 (11.23), and 11i v3 (11.31) | X | X | X | X | |
HP-UX (Itanium 32), 11i (v1.5, v1.6) | X | ||||
IBM AIX (32-bit pSeries), 5.1 - 5.3 | X | X | X | X | X |
IBM AIX PPC (64-bit), 5.3 | X | X | |||
iSeries (OS/400 using PASE), V5R2 | X | X | X | ||
Red Hat Linux (x86), Advanced Server 3, 4, 5 | X | X | X | X | X |
Red Hat Linux (Itanium 64), Advanced Server 3, 4, 5 | X | X | |||
Red Hat Linux (x86 64-bit), Red Hat Enterprise Linux (RHEL) 4 | X | X | X | X | |
Red Hat Linux (zSeries, 31-bit), Advanced Server 3 and 4 | X | X | X | ||
SUSE Linux (X86), 9, 10, and Enterprise Server 9.0 | X | X | X | X | X |
SUSE Linux (Itanium 64), Enterprise Server 8 | X | X | |||
SUSE (X86 64-bit) SUSE Enterprise Server (SLES), 9, 10 | X | X | X | X | |
SUSE Linux (zSeries, 31-bit), version 9 | X | X | X | ||
Sun Solaris (SPARC), 8.x to 10x | X | X | X | X | X |
Sun Solaris (SPARC) 64, 10x | X | X | |||
Sun Solaris (X86), 8.x - 10x | X | X | X | X |
To install the demo version of the SDK, copy the tgz file corresponding to your platform (available on the Web site) to a local directory of your choice. Decompress the tgz file and then extract from the resulting tar file as follows:
gunzip tgzfile tar xvf tarfile
The installation directory should contain the following directory structure:
Directory | Description |
---|---|
/docs | Includes HTML and PDF versions of the manual you are reading right now. |
/redist | Contains a working copy of the UNIX version of the technology. |
/sdk/common | Contains the C include files needed to build or rebuild the technology. |
/sdk/demo | Contains the compiled executables of the sample applications. |
/sdk/resource | Contains localization resource files. See "Changing Resources" for details. |
/sdk/samplecode | Contains a subdirectory holding the source code for a sample application. See Chapter 9, "Sample Applications" for more details. |
/sdk/samplefiles | Contains sample files designed to exercise the technology. |
On UNIX platforms the Outside In products are delivered with a set of shared libraries. All libraries should be installed to a single directory. Depending upon your application, you may also need to add that directory to the system's runtime search path. See Section 3.6, "Environment Variables" for more details.
The following is a brief description of the included libraries and support files. In instances where a file extension is listed as .*, the file extension varies for each UNIX platform (sl on HP-UX, so on Linux and Solaris, and a or o on IBM AIX).
These libraries implement the API. They should be linked with the developer's application.
Library | Description | HTML Export | ImageExport | PDF Export | Search Export | XML Export |
---|---|---|---|---|---|---|
libsc_da.* | Data Access module | X | X | X | X | X |
libsc_ex.* | Export module | X | X | X | X | X |
libsc_fi.* | File Identification module (identifies files based on their contents). | X | X | X | X | X |
The File ID Specification may not be used directly by any application or workflow without it being separately licensed expressly for that purpose.
The following libraries are used for support.
Library | Description | HTML Export | ImageExport | PDF Export | Search Export | XML Export |
---|---|---|---|---|---|---|
liboc_emul.* | Output component emulation module | X | X | X | X | X |
libos_gd.* | The internal rendering GDI implementation. 32-bit Linux and Solaris SPARC only. | X | X | X | X | |
libos_pdf.* | PDF generation module | X | ||||
libos_xwin.* | The native GDI implementation | X | X | X | X | |
libsc_anno.* | The annotation module | X | X | X | ||
libsc_ca.* | Content Access module (provides organized chunker data for the developer) | X | X | X | ||
libsc_ch.* | Chunker (provides caching of and access to filter data for the export engines) | X | X | X | X | X |
libsc_du.* | Display Utilities module (includes text formatting) | X | X | X | X | X |
libsc_fmt.* | Formatting module (resolves numbers to formatted strings) | X | X | X | X | X |
libsc_fut.* | Filter utility module | X | X | X | X | X |
libsc_ind.* | Indexing engine. In Search Export, it handles common functionality. | X | X | X | X | |
libsc_lo.* | Localization library (all strings, menus, dialogs and dialog procedures reside here) | X | X | X | X | X |
libsc_ut.* | Utility functions, including IO subsystem | X | X | X | X | X |
libsc_xp.* | XPrinter bridge | X | X | X | X | |
libwv_core.* | The Abstraction layer | X | X | X | X | X |
libwv_gdlib.so | The GDI rendering module. 32-bit Linux and Solaris SPARC only. | X | X | X | X |
The following libraries are used for display purposes.
Library | Description | HTML Export | Image Export | PDF Export | Search Export | XML Export |
---|---|---|---|---|---|---|
libde_bmp.* | Raster rendering engine (TIFF, GIF, BMP, PNG, PCX…) | X | X | |||
libde_vect.* | Vector/Presentation rendering engine (PowerPoint, Impress, Freelance…) | X | X | X | X | |
libde_ss.* | Spreadsheet/Database (Excel, Calc, Lotus 123…) | X | X | X | ||
libde_tree* | Archive (ZIP, GZIP, TAR…) | X | X | |||
libde_wp.* | Document (Word, Writer, WordPerfect…) | X | X | X |
The following libraries are used for filtering.
libex_gdsf must be linked with libsc_img.* at compile time. This forces the filter to be dependent on libsc_img.* at runtime, even though that module may not be used directly. If you want to reduce your application's physical footprint, you can experiment with unlinking libsc_img.*.
Library | Description | HTML Export | Image Export | PDF Export | Search Export | XML Export |
---|---|---|---|---|---|---|
libvs_*.* | Filters for specific file types (there are more than 150 of these filters, covering more than 500 file formats) | X | X | X | X | X |
libex_gdsf.* | Export filter for GIF, JPEG, and PNG graphics files. | X | X | |||
libsc_img.* | Image conversion module | X | X | X | ||
libex_itext.* | Export filter for SearchText | X | ||||
libex_html .* | Export filter for HTML files | X | ||||
libex_pagelayout.* | Page layout module | X |
The following are graphics filters.
Library | Description | HTML Export | ImageExport | PDF Export | Search Export | XML Export |
---|---|---|---|---|---|---|
i*2.flt | These 30 .flt files are the import filters for premier graphics formats | X | X | X | X | X |
isunx2.flt | Interface to premier graphics filters | X | X | X | X | X |
The following files are also used.
Library | Description | HTML Export | ImageExport | PDF Export | Search Export | XML Export |
---|---|---|---|---|---|---|
adinit.dat | Support file for the vsacad and vsacd2 filters | X | X | X | X | X |
cmmap000.bin | Tables for character mapping (all character sets) | X | X | X | X | X |
cmmap000.sbc | Tables for character mapping (single-byte character sets). This file is located in the /common directory. | X | X | X | X | X |
cmmap000.dbc | Identical to cmmap000.bin, but renamed for clarity (.dbc = double-byte character). This file is located in the common directory. | X | X | X | X | X |
libfreetype.so.6 | TrueType font rendering module for the GD output solution. 32-bit Linux and Solaris SPARC only. | X | X | X | X |
Sample applications are provided with the SDK. These applications demonstrate most of the concepts described in this manual. See Chapter 9, "Sample Applications" for a complete description of the sample applications.
Any source code that uses this product should #include
the file sccex.h and #define
UNIX. For example, a 32-bit UNIX application might have a source file with the following lines:
#define UNIX #include <sccex.h>
and a 64-bit UNIX application might have a source file with the following lines:
#define UNIX #define UNIX_64 #include <sccex.h>
This software is based on the Outside In Viewer Technology (or simply "Viewer Technology"). A file of default options is always created, and a list of available filters and a list of available display engines are also built by the technology, usually the first time the product runs (for UNIX implementations). You do not need to ship these lists with your application.
Lists are stored in the $HOME/.oit directory. If the $HOME environment variable is not set, the files are put in the same directory as the Outside In Technology. If a /.oit directory does not exist in the user's $HOME directory, the .oit directory is created automatically by the technology. The files are automatically regenerated if corrupted or deleted.
The files are:
*.f: Filter lists
*.d: Display engine list
*.opt: Persistent options
The filenames are intended to be unique enough to avoid conflict for any combination of machine name and install directory. This is intended to prevent problems with version conflicts when multiple versions of the Outside In Technology and/or other Outside In Technology-based products are installed on a single system. The filenames are built from an 11-character string derived from the directory the Outside In Technology resides in and the name of the machine it is being run on. The string is generated by code derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm.
The products still function if these files cannot be created for some reason. In that situation, however, significant performance degradation should be expected.
The strings passed in the UNIX API are ISO8859-1 by default.
To optimize performance on systems that do not require DBCS support, a second character mapping bin file, that does not contain any of the DBCS pages, is included. The second bin file gives additional performance benefits for English documents, but cannot handle DBCS documents. To use the new bin file, replace the cmmap000.bin with the new bin file, cmmap000.sbc. For clarity, a copy of the cmmap000.bin file (cmmap000.dbc) is also included. Both cmmap000.sbc and cmmap000.dbc are located in the /sdk/common directory of the technology.
The following is information to consider during run-time.
Some documents that the developer is attempting to convert may contain embedded OLE2 objects. There are platform-dependent limits on what the technology can do with OLE2 objects. However, Outside In attempts to take advantage of the fact that some documents accompany an OLE2 embedding with a graphic "snapshot," in the form of a Windows metafile.
On all platforms, when a metafile snapshot is available, the technology uses it to convert the object. When a metafile snapshot is not available on UNIX platforms, the technology is unable to convert the OLE2 object.
These products trap and handle the following signals:
SIGABRT
SIGBUS
SIGFPE
SIGILL
SIGINT
SIGSEGV
SIGTERM
Developers who wish to override our default handling of these signals should set up their own signal handlers. This may be safely done after the developer's application has called DAInit().
Note: The Java Native Interface (JNI) allows Java code to call and be called by native code (C/C++ in the case of OIT). You may run into problems if Java isn't allowed to handle signals and forward them to OIT. If OIT catches the signals and forwards them to Java, the JVMs will sometimes crash. OIT installs signal handlers when DAInit() is called, so if you call OIT after the JVM is created, you will need to use libjsig. Refer here for more information:http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/signals.html |
Libraries and sample applications are all built with the $ORIGIN variable as part of the binaries' runtime search path. This means that at runtime, OIT libraries will automatically look in the directory they were loaded from to find their dependent libraries. You don't necessarily need to include the technology directory in your LD_LIBRARY_PATH or SHLIB_PATH.
As an example, an application that resides in the same directory as the OIT libraries and includes $ORIGIN in its runtime search path will have its dependent OIT libraries found automatically. You will still need to include the technology directory in your linker's search path at link time using something like -L and possibly -rpath-link.
Another example is an application that loads OIT libraries from a known directory. The loading of the first OIT library will locate the dependent libraries.
Note:
This feature does not work on AIX and FreeBSD.Several environment variables may be used at run time. Following is a short summary of those variables and their usage.
Variable | Description |
---|---|
$PATH | Must be set to include the directory containing the .flt files. Only applicable to AIX. |
$LD_LIBRARY_PATH (FreeBSD, HP-UX Itanium 64, Linux, Solaris) | These variables help your system's dynamic loader locate objects at runtime. If you have problems with libraries failing to load, try adding the path to the Outside In libraries to the appropriate environment variable. See your system's manual for the dynamic loader and its configuration for details.
Note that for products that have a 64-bit PA/RISC, 64-bit Solaris and Linux PPC/PPC64 distributable, they will also go under $LD_LIBRARY_PATH. |
$HOME | Must be set to allow the system to write the option, filter and display engine lists. See "Information Storage" for details. |
The technology includes the following default font alias map for UNIX platforms. The first value is the original font, and the second is the alias.
61 = Liberation Sans
Andale Mono = Liberation Sans
Courier = Liberation Sans
Courier New = Liberation Sans
Lucida Console = Liberation Sans
MS Gothic = Liberation Sans
MS Mincho = Liberation Sans
OCR A Extended = Liberation Sans
OCR B = Liberation Sans
Agency FB = Liberation Sans
Arial = Liberation Sans
Arial Black = Liberation Sans
Arial Narrow = Liberation Sans
Arial Rounded MT = Liberation Sans
Arial Unicode MS = Liberation Sans
Berline Sans FB = Liberation Sans
Calibri = Liberation Sans
Frank Gothic Demi = Liberation Sans
Frank Gothic Medium Cond = Liberation Sans
Franklin Gothic Book = Liberation Sans
Futura = Liberation Sans
Geneva = Liberation Sans
Gill Sans = Liberation Sans
Gill Sans MT = Liberation Sans
Lucida Sans Regular = Liberation Sans
Lucida Sans Unicode = Liberation Sans
Modern No. 20 = Liberation Sans
Tahoma = Liberation Sans
Trebuchet MS = Liberation Sans
Tw Cen MT = Liberation Sans
Verdana = Liberation Sans
Albany = Liberation Sans
Franklin Gothic = Liberation Sans
Franklin Demi = Liberation Sans
Franklin Demi Cond = Liberation Sans
Franklin Gothic Heavy = Liberation Sans
Algerian = Liberation Serif
Baskerville = Liberation Serif
Bell MT = Liberation Serif
Bodoni MT = Liberation Serif
Bodoni MT Black = Liberation Serif
Book Antiqua = Liberation Serif
Bookman Old Style = Liberation Serif
Calisto MT = Liberation Serif
Cambria = Liberation Serif
Centaur = Liberation Serif
Century = Liberation Serif
Century Gothic = Liberation Serif
Century Schoolbook = Liberation Serif
Elephant = Liberation Serif
Footlight MT Light = Liberation Serif
Garamond = Liberation Serif
Georgia = Liberation Serif
Goudy Old Style = Liberation Serif
Lucida Bright = Liberation Serif
MS Serif = Liberation Serif
New York = Liberation Serif
Palatino = Liberation Serif
Perpetua = Liberation Serif
Times = Liberation Serif
times = Liberation Serif
Times New Roman = Liberation Serif
All of the strings used in the UNIX versions of Outside In products are contained in the lodlgstr.h file. This file, located in the resource directory, can be modified for internationalization and other purposes. Everything necessary to rebuild the resource library to use the modified source file is included with the SDK.
In addition to lodlgstr.h, the scclo.o object file is provided. This is necessary for the linking phase of the build. A makefile has also been provided for building the library. The makefile allows building on all of the UNIX platforms supported by Outside In. It may be necessary to make minor modifications to the makefile so the system header files and libraries can be found for compiling and linking.
Standard INCLUDE and LIB make variables are defined for each platform in the makefile. Edit these variables to point to the header files and libraries on your particular system. Other make variables are:
TECHINCLUDE: May need to be edited to point to the location of the Outside In /common header files supplied with the SDK.
BUILDDIR: May need to be edited to point to the location of the makefile, lodlgstr.h, and scclo.o (which should all be in the same directory).
After these variables are set, change to the build directory and type make. The libsc_lo resource library is built and placed in the appropriate platform-specific directory. To use this library, copy it into the directory where the Outside In product is stored and the new, modified resource strings are used by the technology.
Menu constants are included in lomenu.h in the common directory.
The libsc_ex.sl and libsc_da.sl libraries are the only ones that must be linked with your application. They can be loaded when your application starts by linking them directly at compile time or they can be loaded dynamically by your application using library load functions (for example, shl_load).
The shared libraries are dependent on the presence of the X libraries Xm, Xt and X11 if vector graphics support is required. It is the application developer's responsibility to ensure that the needed functions from these libraries are present before the product libraries are used.
The following are example command lines used to compile the sample application exsimple from the /sdk/samplecode directory. The command lines are separated into sections for HP-UX and HP-UX on Itanium (which requires GCC). This command line is only an example. The actual command line required on the developer's system may vary. The example assumes that the include and library file search paths for the technology libraries and any required X libraries are set correctly. If they are not set correctly, the search paths for the include and/or library files must be explicitly specified via the -I include file path and/or -L library file path options, respectively, so that the compiler and linker can locate all required files.
All libraries should be installed into a single directory and the directory must be included in the system's shared library path ($LIBPATH). $LIBPATH must be set and must point to the directory containing the Outside In Technology.
Outside In technology has been updated to increase performance, at a cost of using more memory. It is possible that this increased memory usage may cause a problem on AIX systems, which can be very conservative in the amount of memory they grant to processes. If your application experiences problems due to memory limitations with Outside In, you may be able to fix this problem by using the "large page" memory model.
If you anticipate viewing or converting very large files with Outside In Technology, we recommend linking your applications with the -bmaxdata flag. For example:
cc -o foo foo.c -bmaxdata:0x80000000
If you are currently seeing "illegal instruction" errors followed by immediate program exit, this is likely due to not using the large data model.
The libsc_ex.a and libsc_da.a libraries are the only ones that must be linked with your application. They can be loaded when your application starts by linking them directly at compile time or they can be loaded dynamically by your application using library load functions (for example, load and loadbind) with the .o versions of the libraries provided.
The shared libraries are dependent on the presence of the X libraries Xm, Xt and X11 if vector graphics support is required. It is the application developer's responsibility to ensure that the needed functions from these libraries are present before the product libraries are used.
Note:
If the DISPLAY environment variable is set to point to an X Server on a machine where nobody is currently logged on, any calls to connect to the X Server do not return. They hang the calling application. Therefore, Outside In times out after five seconds of attempting to connect to the X Server if no connection is established in that time.The following is an example command line used to compile the sample application exsimple from the /sdk/samplecode directory. This command line is only an example. The actual command line required on the developer's system may vary. The example assumes that the include and library file search paths for the technology libraries and any required X libraries are set correctly. If they are not set correctly, the search paths for the include and/or library files must be explicitly specified via the -I include file path and/or -Llibrary file path options, respectively, so that the compiler and linker can locate all required files.
Developers may need to use the -qcpluscmt flag to allow C++ style comments.
Two versions of some AIX modules are included in this package. If the libsc_ex.o and libsc_da.o files are included on the compiler's command line with a path it causes that path to be hard coded in the executable. The -L option does not detect object files, and forcing developers to keep a copy of these files in their own source directory would be clumsy at best. On the other hand, load does not work with library archive files, only with object files.
This section discusses issues involving Linux compiling and linking.
This section discusses Linux compatibility issues when using libraries.
The following table indicates the compiler version used and the minimum required version of the GNU standard C library needed for Outside In operation.
Distribution | Compiler Version | GLIBC Version |
---|---|---|
x86 Linux | 3.3.2 | libc.so.6 (2.3 or newer) |
In addition to libc.so.6, Outside In is dependent upon the following libraries:
libstdc++.so.5.0.5
libgcc_so.1
libgcc_s.so.1 was introduced with GCC 3.0, so any distribution based on a pre-GCC 3.0 compiler does not include libgcc_s.so.1.
The following table summarizes what is included with the RedHat and SUSE distributions supported by Outside In and what needs to be added/modified to make Outside In run on these systems. Developers may have trouble building with libstdc++.so.5 versions before 5.0.5 due to unversioned symbols. Upgrade to 5.0.5 to correct the problem.
Advanced Server 3.0
Included | To be added |
---|---|
libc.so.6 version | /lib/libc-2.3.2 |
libstdc++ | /usr/lib/libstdc++.so.5.0.3 |
libgcc_s.so.1 | /lib/libgcc_s.so-3.2.3-20030829.so.1 |
Required to Use Outside In |
|
Advanced Server 4.0
Included | To be added |
---|---|
libc.so.6 version | /lib/libc-2.3.4 |
libstdc++ | /usr/lib/libstdc++.so.6.0.3 |
libgcc_s.so.1 | /usr/lib/libgcc_s.so-3.4.3-20041213.so.1 |
Required to Use Outside In |
|
SUSE 8.1
Included | To be added |
---|---|
libc.so.6 version | /lib/libc.so.6 (GLIBC 2.2.5) |
libstdc++ | /usr/lib/libstdc++.so.5.0.0 |
libgcc_s.so.1 | /lib/libgcc_s.so.1 |
Required to Use Outside In |
|
SUSE 9.0
Included | To be added |
---|---|
libc.so.6 version | /lib/libc.so.6 (GLIBC 2.3.4) |
libstdc++ | /usr/lib/libstdc++.so.5.0.6 + old libraries |
libgcc_s.so.1 | /lib/libgcc_s.so.1 |
Required to Use Outside In |
|
SUSE 8.1
Included | To be added |
---|---|
libc.so.6 version | /lib/libc.so.6 (GLIBC 2.2.5) |
libstdc++ | /usr/lib/libstdc++.so.5.0.0 |
libgcc_s.so.1 | /lib/libgcc_s.so.1 |
Required to Use Outside In |
|
SUSe 9.0
Included | To be added |
---|---|
libc.so.6 version | /lib/libc.so.6 (GLIBC 2.3.4) |
libstdc++ | /usr/lib/libstdc++.so.5.0.6 + old libraries |
libgcc_s.so.1 | /lib/libgcc_s.so.1 |
Required to Use Outside In |
|
SUSE Linux Enterprise Server 8.0
Included | To be added |
---|---|
libc.so.6 version | /lib/libc.so.6.1 (GLIBC 2.2.6) |
libstdc++ | /usr/lib/libstdc++-libc6.2-2.so.3
/usr/lib/libstdc++.so.5.0.0 |
libgcc_s.so.1 | /lib/libgcc_s.so.1 |
Required to Use Outside In |
|
The libsc_ex.so and libsc_da.so are the only libraries that must be linked with your applications. They can be loaded when your application starts by linking them directly at compile time or they can be loaded dynamically by your application using library load functions (for example, dlopen).
To use PDF Export annotation functions, you must also link to libsc_ca.so, requiring a separate license to Outside In Content Access or Search Export. Contact your Outside In sales representative for more information.
The following are example command lines used to compile the sample application exsimple from the /sdk/samplecode directory. This command line is only an example. The actual command line required on the developer's system may vary.
The example assumes that the include and library file search paths for the technology libraries and any required X libraries are set correctly. If they are not set correctly, the search paths for the include and/or library files must be explicitly specified via the -I include file path and/or -L library file path options, respectively, so the compiler and linker can locate all required files.
Note:
These products do not support the "Solaris BSD" mode.All libraries should be installed into a single directory. The libsc_ex.so, and libsc_da.so libraries must be linked with your application. It can be loaded when your application starts by linking them directly at compile time or they can be loaded dynamically by your application using library load functions (for example, dlopen).
The command line below is used to compile the sample application exsimple from the /sdk/samplecode directory. This command line is only an example. The actual command line required on the developer's system may vary. The example assumes that the include and library file search paths for the technology libraries and any required X libraries are set correctly. If they are not set correctly, the search paths for the include and/or library files must be explicitly specified via the -I include file path> and/or -L library file path options, respectively, so that the compiler and linker can locate all required files.
Developers may need to use the -xcc flag to allow C++ style comments.
cc -w -o ../exsimple/unix/exsimple ../exsimple/unix/exsimple.c -I/usr/include -I/usr/dt/share/include -I../../common -L../../demo -L/usr/lib -L/lib -lsc_ex -lsc_da -Wl,-R,../../demo -Wl,-R,'${ORIGIN}'
Note: When running the 32-bit SPARC binaries on Solaris 8 or 9 systems, you may see the following error:
ld.so.1: simple: fatal: libm.so.1: version `SUNW_1.1.1' not found (required by file ./libsc_vw.so)
This is due to a missing system patch. Please apply one of the following patches (or its successor) to your system to correct.
For Solaris 8 - Patch 111721-04
For Solaris 9 - Patch 111722-04