This chapter covers some issues specific to using the Export products.
This chapter includes the following sections:
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.
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.
Four issues have been encountered when using Image Export:
If a spreadsheet contains embedded graphics, embedded charts, or merged cells that cross page boundaries, Image Export does not clip these objects correctly. The objects appear in the correct position, but they bleed into the margins. In addition, some information may be duplicated on multiple pages as a result of this improper clipping. These errors should never result in information being omitted from the output.
When processing fonts that are not TrueType fonts, the output graphic will contain text that appears "blocky" as a result of shortcomings in Image Export's smoothing algorithm.
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 prevents the software from exporting unidentified binary files as though they were text.