Implementation Issues

2.1 Running in 24x7 Environments

To ensure robust 24x7 performance in server applications embedding the different export products, it is strongly recommended that the technology be run in a process separate from the server's primary process.

The file filtering technology underlying the technology represents almost a quarter of a million lines of code. This code is expected to robustly deal with any stream of bytes, of any length (any file), in all cases. Oracle has dedicated, and continues to dedicate, significant effort into making this technology extremely robust. However, in real world situations, expect that some small number of malformed files may force the filters into unstable states. This generally results in either a memory exception (which can be trapped and recovered from gracefully), infinite loop or a wild pointer that causes the filter to write into memory that is part of the same process but does not belong to the filter. In the latter situation, this wild pointer condition cannot be trapped.

On the desktop this is not a significant problem since the number of files being dealt with is relatively small. In a 24x7 server environment, however, a wild pointer can be extremely disruptive to the server process and produce serious problems. The best solution for dealing with this problem is to run any application that reads complex file formats in a separate process. This solution protects the application from the susceptibility of filtering technology to the unknown quality of input files.

It must be stressed that files that lead to wild pointers or infinite loops occur very infrequently, usually as a result of a third-party conversion process or beta versions of applications. Oracle is committed to addressing these issues and to updating and expanding its testing tools and corpus of documents to proactively minimize this "garbage in-garbage out" problem.

2.2 Running in Multiple Threads or Processes

On certain platforms, export products may be run in a multi-threaded or multi-processing application. The thing to remember when doing so is that each thread must go through all the steps listed in Introduction.

2.3 PDF Export Issues

The following issues have been identified when using PDF Export:

There is currently no method of specifying how wide a field in a database should be. Occasionally this will lead to situations where information in a database field will not be included in the output graphic, resulting in a loss of content.
If multiple pages of garbage output occur when exporting images, it is possible that the default setting of the SCCOPT_FALLBACKFORMAT (FallbackFormatEnum on the server version) option (FI_ASCII-8) is forcing the technology to attempt to read files that it cannot identify as text. Setting the pertinent option to the value FI_NONE (FallbackFormat on the server version) prevents the software from exporting unidentified binary files as though they were text.
The SCCOPT_FONTDIRECTORY option must be set.
Only TrueType fonts are supported in PDF Export at this time.