| Oracle® Outside In HTML Export Developer's Guide Release 8.3.7 Part Number E12884-02 |
|
|
View PDF |
| Oracle® Outside In HTML Export Developer's Guide Release 8.3.7 Part Number E12884-02 |
|
|
View PDF |
Options are parameters affecting the behavior of an export or transformation. This chapter presents both the C/C++ and SOAP options relevant to the HTML Export product.
While default values are provided, users are encouraged to set all options for a number of reasons. In some cases, the default values were chosen to provide backwards compatibility. In other cases, the default values were chosen arbitrarily from a range of possibilities.
One reason that users may want to avoid using the default value for an option is that the default value may change from one release to the next. This is because as standards evolve over time, defaults may be updated to reflect the current status of the technology.
These options are available to the developer when using the export engine.
Options are set using the DASetOption call. It is recommended that developers familiarize themselves with all of the options available.
Options may be Local, in which case they only affect the handle for which they are set, or Global, in which case they automatically affect all handles associated with the hDoc and must be set before the call to DAOpenDocument.
Of course some options are more important than others. Casual users of this API should focus on the following (in rough order of importance):
This section discusses character mapping options.
This option is used in cases where Outside In cannot determine the character set used to encode the text of an input file. When all other means of determining the file's character set are exhausted, Outside In will assume that an input document is encoded in the character set specified by this option. This is most often used when reading plain-text files, but may also be used when reading HTML or PDF files. The possible character sets are listed in charsets.h.
When "extended test for text" is enabled (see Section B.1.3.2, "SCCOPT_FIFLAGS"), this option will still apply to plain-text input files that are not identified as EBCDIC or Unicode.
This option supersedes the SCCOPT_FALLBACKFORMAT option for selecting the character set assumed for plain-text files. For backwards compatibility, use of deprecated character-set -related values is still currently supported for SCCOPT_FALLBACKFORMAT, though internally such values will be translated into equivalent values for the SCCOPT_DEFAULTINPUTCHARSET. As a result, if an application were to set both options, the last such value set for either option will be the value that takes effect.
Handle Types
NULL, VTHDOC
Scope
Global
Data Type
VTDWORD
Default
ANSI1252 on Windows and Latin-1 on UNIX.
Data
The data types are listed in charsets.h.
This option determines the byte order of Unicode characters in the output files when Unicode is chosen as the output character set.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
One of the following values:
SCCEX_CHARBYTEORDER_BIGENDIAN: Big-Endian byte ordering is common on RISC and Motorola processors. The ISO 10646 standard, the Unicode Standard and the W3C recommend Big-Endian Unicode. It also corresponds to network byte order.
SCCEX_CHARBYTEORDER_LITTLEENDIAN: Little Endian is common on Intel processors.
SCCEX_CHARBYTEORDER_TEMPLATE: This value will cause the output to use the byte ordering used in the main template file, if the template is written in Unicode. If the template is not written in Unicode, Big-Endian byte order is used.
Default
SCCEX_CHARBYTEORDER_TEMPLATE
This option allows the developer to specify which character set should be used in the output file. The technology will then translate or "map" characters from the input document's character set to the output character set as needed. Naturally, export process does not translate content from one language to another. This character mapping is also clearly limited by the need for the character to be in both the input and the output character sets. If a character cannot be mapped, the character will show up in the output as the "unmappable character." The default unmappable character used is the asterisk (*). The character used may be changed by setting the SCCOPT_UNMAPPABLECHAR option. If the resulting output contains an excessive number of asterisks, selecting a more appropriate output character set should improve the situation.
The technology reserves the right to override this option. The option will be overridden if ANSI Double-Byte Character Set (DBCS) characters are detected in the source document and a single-byte character set is chosen as the output character set. If the option is overridden, this change will affect the entire output document. The technology uses the first DBCS character set it finds in the document as the basis for its decision about which output character set to choose as its override.
Note that special character set override rules apply when the input document uses the HWP (Hangul 97) filter. For these documents, the output character set will be forced to SO_ANSI949 (euc-kr) unless the user has selected euc-kr, Unicode or UTF-8 output. These override rules do not apply to the HWP2 (Hangul 2002) filter, as it uses Unicode exclusively.
Source documents in Unicode will not override this option. This is especially important to remember as some important file formats store text in Unicode including Microsoft Office.
The markup standards currently supported by HTML Export limit documents to a single character set. That character set is specified in an output file using the CONTENT attribute of the <meta> tag. This limits what the technology can do with documents that have multiple character sets. In general, documents that are a mix of a single Asian language and English characters will translate correctly (although with some possible loss of non-alphanumeric characters) if the appropriate DBCS, UTF-8 or Unicode output character set is selected. This is because most DBCS character sets include the standard 7-bit Latin 1 characters. Documents that contain more than one DBCS character set or a DBCS character set and a non-English character set (such as Cyrillic) may not export with all the character glyphs intact unless Unicode or UTF-8 is used.
Source documents that contain characters from many character sets will look best only when this option is set to Unicode or UTF-8. This is because the Unicode and UTF-8 character sets contain almost all characters for the most common languages.
While the W3C recommends using Unicode, there is a downside to it at this time. Not all systems have the appropriate fonts needed for using Unicode or UTF-8. Many editors do not understand these character sets, as well. In fact, while HTML Export can read Unicode source documents, it cannot read UTF-8 source documents. In addition, there are some differences in the way browsers interpret the byte order of 2-byte Unicode characters. For additional details about the byte ordering issue, see Section B.1.1.2, "SCCOPT_EX_CHARBYTEORDER."
An additional HTML browser idiosyncrasy affects the Netscape 4.0 – 6.0 browsers. While these browsers properly render Unicode HTML, they seem to be unable to read .css files that are written in Unicode. For this reason, if the output character set is Unicode and the HTML flavor (described in Section B.1.2.5, "SCCOPT_EX_FLAVOR") being generated is Netscape 4.0 or the common 4.0 flavor, the associated .css file will be written in UTF-8.
In order for HTML Export to correctly place the character set into the output file it generates, all templates should include a statement that uses the {## insert} macro to insert the character set into the document, as in the following example:
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset={## insert element=pragma.charset}" />
If the template does not include this line, the user may have to manually select the correct character set in the user's browser.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
One of the following values:
| Value | Description |
|---|---|
| CS_DOS_437 | U.S. |
| CS_DOS_737 | Greek |
| CS_DOS_850 | Latin-1 |
| CS_DOS_852 | Latin-2 |
| CS_DOS_855 | Cyrillic |
| CS_DOS_857 | Turkish |
| CS_DOS_860 | Portuguese |
| CS_DOS_863 | French Canada |
| CS_DOS_865 | Denmark, Norway-DAT |
| CS_DOS_866 | Cyrillic |
| CS_DOS_869 | Greece |
| CS_WINDOWS_874 | Thailand |
| CS_WINDOWS_932 | Japanese |
| CS_WINDOWS_936 | Chinese GB |
| CS_WINDOWS_949 | Korea (Wansung) |
| CS_WINDOWS_950 | Hong Kong, Taiwan |
| CS_WINDOWS_1250 | Windows Latin 2 (Central Europe) |
| CS_WINDOWS_1251 | Windows Cyrillic (Slavic) |
| CS_WINDOWS_1252 | Windows Latin 1 (ANSI) |
| CS_WINDOWS_1253 | Windows Greek |
| CS_WINDOWS_1254 | Windows Latin 5 (Turkish) |
| CS_WINDOWS_1255 | Windows Hebrew |
| CS_WINDOWS_1256 | Windows Arabic |
| CS_WINDOWS_1257 | Windows Baltic |
| CS_UNICODE | Unicode |
| CS_UTF8 | UTF-8 |
| CS_ISO8859_1 | Latin-1 - this is a subset of Windows 1252 |
| CS_ISO8859_2 | Latin-2 |
| CS_ISO8859_3 | Latin-3 |
| CS_ISO8859_4 | Latin-4 |
| CS_ISO8859_5 | Cyrillic |
| CS_ISO8859_6 | Arabic |
| CS_ISO8859_7 | Greek |
| CS_ISO8859_8 | Hebrew |
| CS_ISO8859_9 | Turkish |
Default
CS_WINDOWS_1252
This option selects the character used when a character cannot be found in the output character set. This option takes the Unicode value for the replacement character. It is left to the user to make sure that the selected replacement character is available in the output character set.
Note that when exporting to the 4.0 and higher flavors, HTML Export will not have any unmappable characters in its HTML. Instead, it will write the unmapped character out in &#....; notation using the decimal representation of the character's Unicode value. Newer browsers support this representation and will convert it to the appropriate character if it is available in the font being used. If the character is not available in that font, the browser's unmappable character symbol (typically a rectangular box) will be seen. Also note that there may still be unmapped characters in text rendered to graphics. This is because the graphic file is generated by HTML Export at conversion time rather than being rendered by the browser.
Care should be taken in choosing which character to use for the unmappable character. The character should be one that will create minimal confusion between those characters that were correctly mapped, and characters that were unmapped. Not only does such confusion make reading the document more difficult, it can cause additional problems as well. For example, if the unmappable character is also a character in the name of a font being used in the output, HTML Export may become unable to use that font. In general, letters and numbers make poor choices for the value of this option.
Handle Types
VTHDOC
Scope
Local
Data Type
VTWORD
Data
The Unicode value for the character to use.
Default
0x002a = "*"
This section describes output options.
The setting for this option determines whether or not change tracking information in input documents will be written into the output via the <ins> and <del> HTML tags. When the option is set to FALSE, no change tracking information will be written into the output. When set to TRUE, the <ins> and <del> tags will be used as appropriate.
Previous versions of HTML Export included change tracking text in comments.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Default
FALSE
This is an advanced option that casual users of HTML Export may safely ignore.
When set, this option deletes whitespace from the output document. Two types of whitespace are removed: redundant whitespace characters and vertical whitespace. This option is intended for situations where bandwidth and screen space are limited.
The HTML standard specifies that the browser will collapse a sequence of whitespace characters into a single whitespace character. Therefore, having HTML Export remove these redundant whitespace characters has no effect on the final view of the document. Removing them benefits the document in reducing the overall size of the output files generated and thereby saves bandwidth and decreases file transmission times. While HTML Export makes an effort to remove as much redundant whitespace as possible, there will be cases where some extra spacing appears in the output.
Removing vertical whitespace, on the other hand, does affect the look of the document in the browser. When possible, HTML Export preserves vertical spacing between elements. However, when this option is set, vertical whitespace is removed, resulting in a more compact view.
Please note that the collapse white space option does not affect whitespace coming from the template.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Data
One of the following values:
TRUE: Whitespace is removed.
FALSE: Whitespace is left intact.
Default
FALSE
This option allows the developer to force the output to be compliant with a given standard. Currently, only DTD and well-formed compliance are supported. The option takes the form of a set of bit flags for toggling the available options. Flags are off by default and are turned on by bitwise OR-ing them together.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
Any of the following flags bitwise OR-ed together:
SCCEX_CFLAG_STRICT_DTD: Set to enforce strict DTD compliance in the HTML written. The resulting HTML will be well formed. This means that an XML parser can parse it. In addition, "safe" HTML tags normally written by HTML Export are turned off when this flag is set. For more information about "safe" tags, see Section B.1.2.5, "SCCOPT_EX_FLAVOR."
Especially when using older HTML flavors, use of this flag somewhat diminishes the fidelity of the view of the output document compared to the original document. In addition to other changes to the output, setting this flag also has the same effect as setting the SCCOPT_EX_PREVENTGRAPHICOVERLAP option to TRUE.
This flag should not be used with the SCCEX_CFLAG_WELLFORMED flag. If they are both set, this flag will override the well-formed flag.
Most users will probably want to use the SCCEX_CFLAG_WELLFORMED flag instead of this flag.
SCCEX_CFLAG_WELLFORMED: Set to force the HTML written to be well formed. This means that an XML parser can parse it. This option differs from the SCCEX_CFLAG_STRICTDTD flag in that it allows "safe" tags. This flag should not be used with the SCCEX_CFLAG_STRICTDTD flag. If they are both set, the strict DTD flag will override this flag. For most users, this flag is recommended over the use of the SCCEX_CFLAG_STRICTDTD flag as it produces well formed, XHTML compliant HTML without the penalties imposed by the strict DTD flag.
Default
0: All flags turned off.
This option controls the extraction of attached documents in the input document. When set to SCCEX_EXTRACT_BINARY, the attachment will be extracted in its native format, allowing it to be read by the authoring application. When set to SCCEX_EXTRACT_CONVERT, the attachment will be extracted as HTML. When set to SCCEX_EXTRACT_OFF, the attachment will be ignored.
This option is only valid for UUE, MIME and MSG files and not for general purpose file attachments.
Data Size
VTDWORD
Handle Types
VTHDOC, VTHEXPORT
Data
SCCEX_EXTRACT_OFF: Embeddings are skipped.
SCCEX_EXTRACT_CONVERT: Embeddings are converted.
SCCEX_EXTRACT_BINARY: Embeddings are extracted in their native file format.
Default
SCCEX_EXTRACT_OFF
Each Web browser forms a de facto HTML standard. This is because each browser has a unique collection of HTML tags and tag attributes it does or does not support. Thus, there are a large number of browser-based variations on the official HTML standards that are referred to here as "flavors" of HTML.
This option allows the developer to tailor the output generated to a specific browser or for a specific minimum browser. This allows HTML Export to produce the best possible rendering of the source document given the tags available in the target flavor. It also gives the OEM the ability to specify which standard their product will adhere to, rather than having that standard be dictated by HTML Export.
HTML Export currently supports a large number of flavors. While some flavors are targeted at specific browsers, other flavors are designed for a more abstract target. The "generic" and "HTML 2.0" flavors provide "lowest common denominator" flavors. The HTML produced by these flavors is very simple and should work in almost any browser. The primary difference between these two flavors is that the generic flavor supports tables and the HTML 2.0 flavor does not.
At other times, it is desirable to have the ability to create HTML that simply supports "the major x.0 and later browsers." For this purpose, there are the "greatest common denominator" flavors. They are the "3.0" and "4.0" flavors. The "3.0" flavor should be used to create HTML that will look good in Netscape Navigator 3.0 or later and in Microsoft Internet Explorer 3.0 or later. The "4.0" flavor is defined to look good in Netscape Navigator 4.0 or later and in Microsoft Internet Explorer 4.0 or later. Note that upon examining the capabilities of these browsers after the 4.0 versions, it was determined that while they offer many new features, they do not have any .html or .css extensions that are useful to HTML Export at this time.
Naturally, support for a particular HTML flavor does not mean that HTML Export will generate all the tags and tag attributes that flavor supports. There are many tags and attributes that cannot sensibly be used in an automated conversion setting. Such tags require more information about the author's intent than is available in the source document.
Exporting a document to a particular HTML flavor also does not mean that the resulting HTML will be limited to only the tags and tag attributes supported by that flavor. In many cases, HTML Export will write out extra "safe" tags to the document, unless SCCOPT_EX_COMPLIANCEFLAGS has the SCCEX_CFLAG_STRICT_DTD flag set. The target browser will safely ignore this extra HTML. However, should the converted document be viewed in a more sophisticated browser, this extra information will be used to produce a more accurate view of the document.
What support for a particular HTML flavor does mean is that the HTML generated will look as good as possible when viewed in the appropriate browser.
Note that support for the following flavors have been deprecated and now automatically map to SCCEX_FLAVOR_GENERICHTML:
SCCEX_FLAVOR_MO21
SCCEX_FLAVOR_NS11
SCCEX_FLAVOR_NS20
SCCEX_FLAVOR_MS15
SCCEX_FLAVOR_MS20
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
One of the following values (flavors marked with "(CSS)" require a separate or embedded .css file to be created as part of the document conversion):
SCCEX_FLAVOR_GENERICHTML: General purpose, simple HTML support that should look good in any browser that supports tables.
SCCEX_FLAVOR_HTML20: HTML 2.0. Based on the official HTML 2.0 standard, this provides minimal HTML support and per that standard, it does not support tables.
SCCEX_FLAVOR_HTML30: Should look good in both Netscape Navigator 3.0 or later and Microsoft Internet Explorer 3.0 or later.
SCCEX_FLAVOR_HTML40: Should look good in both Netscape Navigator 4.0 or later and Microsoft Internet Explorer 4.0 or later (CSS).
SCCEX_FLAVOR_NS30: Netscape Navigator 3.0
SCCEX_FLAVOR_NS40: Netscape Navigator 4.0 (CSS)
SCCEX_FLAVOR_MS30: Microsoft Internet Explorer 3.0. Note that while this flavor has limited CSS support, it does not create a separate or embedded .css file.
SCCEX_FLAVOR_MS40: Microsoft Internet Explorer 4.0 (CSS)
Default
SCCEX_FLAVOR_HTML40
This is an advanced option that casual users may safely ignore.
This option turns off writing of characters that are produced strictly to make the output more readable and visually appealing. Currently, those formatting characters are limited to newlines, carriage returns and spaces. This option is of benefit primarily to users who perform special automated processing on the text produced by the technology. For these users, even benign non-markup text not originally in the source document constitutes a source of extra headaches for their processing. Setting this option excludes all formatting characters from appearing in the generated markup.
It is important to note the things that setting this option does not do:
While setting this option will make it very difficult for a human to read the generated markup in a text editor, it does not affect the browser's rendering of the document.
This option does not affect the contents of the .css files since they do not contain any text from the source document.
The option does not affect spaces or newlines copied from the template as the contents of the templates are already under the control of the customer.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Data
One of the following values:
TRUE: Do not output formatting characters.
FALSE: Include formatting characters in the output.
Default
FALSE
The setting for this option determines whether or not hidden data (hidden columns, rows or sheets) in a spreadsheet will be included in the output. When set to FALSE (the default), the hidden elements are not written. When set to TRUE, they are placed in the output in the same manner as regular spreadsheet data.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Data
TRUE: Allow hidden data to be placed in the output.
FALSE: Prevent hidden data from being placed in the output.
Default
FALSE
This option will force HTML Export to place all hidden text in line with surrounding text.
Please note that enabling this option will not display hidden cells, hidden rows or hidden sheets in spreadsheet documents. Also note that when graphic documents (such as faxes) are processed by OCR software and converted to PDF, the optically recognized text may be rendered as a layer of hidden text behind the original image. In order to properly export such PDF documents, this option must be enabled.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Data
TRUE: Allow hidden text to be placed in the output.
FALSE: Prevent hidden text from being placed in the output.
Default
FALSE
This option is for use by people who intend to read or change the CSS style names generated by HTML Export.
By default, HTML Export creates unique style names based on the style names used in the original document. Unfortunately, there is an inherent limitation in the style names the CSS standard permits. That standard only permits the characters [a-z][A-Z][0-9] and "-". Source document style names do not necessarily have this restriction. In fact they may even contain Unicode characters at times. For this reason, the original style names may need to be modified to conform to this standard. To avoid illegal style names, HTML Export performs the following substitutions on all source style names:
If the character is a "-", then it is replaced with "--".
If the character is not one of the remaining characters ([a-z][A-Z][0-9]), then it is replaced by "-xxxx" where "xxxx" is the Unicode value of the character in hexadecimal.
Otherwise the character appears in the style name normally.
An example of one of the most common examples of this substitution is that spaces in style names are replaced with "-0020". For a more complete example of this character substitution in style names, consider the source style name My Special H1-Style!. This would be transformed to:
My-0020Special-0020H1--Style-0021
While admittedly this system lacks a certain aesthetic, it avoids the problem of how the document looks when the browser receives duplicate or invalid style names. Developers should also appreciate the simplicity of the code needed to parse or create these style names.
In addition, HTML Export will sometimes create special character attribute-only versions of styles. These have the same name as the style they are based on with "--Char" appended to the end. These styles differ from their original counterparts in that they contain no block level CSS. This more general solution replaces the solution implemented in versions 7.1 and earlier which created "--List" styles to solve a subset of this problem. This was done to work around limitations in some browsers.
Because of these CSS limitations, the SCCOPT_EX_SIMPLESTYLENAMES option was created. Setting this option to TRUE causes HTML Export to generate style names that are easy to read but are not guaranteed to be unique. It does this by discarding all characters in the original style name that are not legal in CSS style names. As one would expect, this may lead to naming collisions.
An example of a naming collision caused by setting this option can be seen if you look at source document styles named MyStyle and My $ Style. When exported with this option, both would become MyStyle. This in turn may generate confusion when viewing the document in the browser. This is because the browser will look upon the second style as being a redefinition of the first.
With the option set to FALSE this is not a problem. The two styles would be converted to MyStyle and My-0020-0024-0020Style respectively. Because the style names are unique, the browser will not see the second style as a redefinition of the first.
As this contrived example indicates, naming collisions should be rare for most U.S. documents.
If a style name consists of nothing but illegal characters, HTML Export will create a style name for it. This style name is of the form UnnamedStyleX where X is a count of styles encountered so far that did not have style names for one reason or another. This behavior is expected to be very common when converting international documents in languages that are not based on 7-bit ASCII.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Data
One of the following values:
TRUE: Generate names that may not be unique, but are easy to read.
FALSE: Generate unique style names that are difficult to read.
Default
FALSE
This option is only valid on 32-bit Linux (Red Hat and Suse) and Solaris Sparc platforms.
When this option is set to TRUE, the technology will attempt to use its internal graphics code to render fonts and graphics. When set to FALSE, the technology will render images using the operating system's native graphics subsystem (X11 on UNIX/Linux platforms). Note that this option only works when at least one of the appropriate output solutions is present. For example, if the UNIX $DISPLAY variable does not point to a valid X Server, but the OSGD and/or WV_GD modules required for the Outside In output solution exist, Outside In will default to the Outside In rendering code. The option will fail if neither of these output solutions is present.
It is important for the system to be able to locate useable fonts when this option is set to TRUE. Only TrueType fonts (*.ttf or *.ttc files) are currently supported. To ensure that the system can find them, make sure that the environment variable GDFONTPATH includes one or more paths to these files. If the variable GDFONTPATH can't be found, the current directory is used. If fonts are called for and cannot be found, HTML Export will exit with an error. Also note that when copying Windows fonts to a UNIX system, the font extension for the files (*.ttf or *.ttc) must be lowercase, or they will not be detected during the search for available fonts. Oracle does not provide fonts with any Outside In product.
Handle Types
NULL, VTHDOC
Scope
Global
Data Type
VTBOOL
Data
One of the following values:
TRUE: Use the technology's internal graphics rendering code to produce bitmap output files whenever possible.
FALSE: Use the operating system's native graphics subsystem.
Default
FALSE
This section describes input handling options.
This option controls how files are handled when their specific application type cannot be determined. This normally affects all plain-text files, because plain-text files are generally identified by process of elimination, for example, when a file isn't identified as having been created by a known application, it is treated as a plain-text file.
This option must be set for an hDoc before any subhandle has been created for that hDoc.
A number of values that were formerly allowed for this option have been deprecated. Specifically, the values that selected specific plain-text character sets are no longer to be used. Instead, applications should use the SCCOPT_DEFAULTINPUTCHARSET option for such functionality.
Handle Types
NULL, VTHDOC
Scope
Global
Data Type
VTDWORD
Data
The high VTWORD of this value is reserved and should be set to 0, and the low VTWORD must have one of the following values:
FI_TEXT: Unidentified file types will be treated as text files.
FI_NONE: Outside In will not attempt to process files whose type cannot be identified. This will include text files. When this option is selected, an attempt to process a file of unidentified type will cause Outside In to return an error value of DAERR_FILTERNOTAVAIL (or SCCERR_NOFILTER).
Default
FI_TEXT
This option affects how an input file's internal format (application type) is identified when the file is first opened by the Outside In technology. When the extended test flag is in effect, and an input file is identified as being either 7-bit ASCII, EBCDIC, or Unicode, the file's contents will be interpreted as such by the export process.
The extended test is optional because it requires extra processing and cannot guarantee complete accuracy (which would require the inspection of every single byte in a file to eliminate false positives.)
Handle Types
NULL, VTHDOC
Scope
Global
Data Type
VTDWORD
Data
One of the following values:
SCCUT_FI_NORMAL: This is the default value. When this is set, standard file identification behavior occurs.
SCCUT_FI_EXTENDEDTEST: If set, the File Identification code will run an extended test on all files that are not identified.
Default
SCCUT_FI_NORMAL
This option allows the developer to set flags that enable options that span multiple export products.
Handle Types
VTHDOC
Scope
Local
Data Type
VTDWORD
Data
SCCOPT_FLAGS_ALLISODATETIMES: When this flag is set, all Date and Time values are converted to the ISO 8601 standard. This conversion can only be performed using dates that are stored as numeric data within the original file.
SCCOPT_FLAGS_STRICTFILEACCESS: When an embedded file or URL can't be opened with the full path, OIT will sometimes try and open the referenced file from other locations, including the current directory. When this flag is set, it will prevent OIT from trying to open the file from any location other than the fully qualified path or URL.
0: All flags turned off
Default
0: All flags turned off
This option can disable the password verification of files where the contents can be processed without validation of the password. If this option is not set, the filter should prompt for a password if it handles password-protected files.
As of Release 8.3.5, only the PST Filter supports this option.
Scope
Global
Data Type
VTBOOL
Data
TRUE: Ignore validation of the password
FALSE: Prompt for the password
Default
FALSE
This option allows the developer to specify the location of a Lotus Notes or Domino installation for use by the NSF filter. A valid Lotus installation directory must contain the file nnotes.dll.
Note:
Please see section 2.1.1 for NSF support on Win32 or section 3.1.1 for NSF support on Linux x86-32 or Solaris Sparc 32.Handle Types
NULL
Scope
Global
Data Type
VTLPBYTE
Data
A path to the Lotus Notes directory.
Default
If this option isn't set, then OIT will first attempt to load the Lotus library according to the operating system's PATH environment variable, and then attempt to find and load the Lotus library as indicated in HKEY_CLASSES_ROOT\Notes.Link.
Adobe's Extensible Metadata Platform (XMP) is a labeling technology that allows you to embed data about a file, known as metadata, into the file itself. This option enables parsing of the XMP data into normal OIT document properties. Enabling this option may cause the loss of some regular data in premium graphics filters (such as Postscript), but won't affect most formats (such as PDF).
Handle Types
VTHDOC
Scope
Local
Data Type
VTBOOL
Data
TRUE: This setting enables parsing XMP.
FALSE: This setting disables parsing XMP.
Default
FALSE
This option controls whether or not the PDF filter will attempt to reorder bidirectional text runs so that the output is in standard logical order as used by the Unicode 2.0 and later specification. This additional processing will result in slower filter performance according to the amount of bidirectional data in the file.
Handle Types
VTDOC, NULL
Scope
Global
Data Type
VTDWORD
Data
SCCUT_FILTER_STANDARD_BIDI
SCCUT_FILTER_REORDERED_BIDI
Default
SCCUT_FILTER_STANDARD_BIDI
This option allows the user to define an offset to GMT that will be applied during date formatting, allowing date values to be displayed in a selectable time zone. This option affects the formatting of numbers that have been defined as date values (e.g., most dates in spreadsheet cells). This option will not affect dates that are stored as text.
Handle Types
NULL, VTHDOC
Scope
Global
Data Type
VTLONG
Data
Integer parameter from -96 to 96, representing 15-minute offsets from GMT. To query the operating system for the time zone set on the machine, specify SCC_TIMEZONE_USENATIVE.
Default
0: GMT time
This section describes layout options.
Determines what font will be used when the font specified by the document is not available.
Currently this option is only used in certain situations where a CSS flavor of HTML is in use. Specifically, this option helps to avoid problems in some browsers where symbol fonts like Wingdings are used for the bullets in lists, and the body of the list is in a font the browser cannot find. In this case, specifying a fallback font prevents the browser from using/cascading the Wingdings font into the text of the list when the browser cannot find the font specified for the list text.
To turn off the fallback font, this option must be explicitly set to an empty string (""). While turning off the fallback font is not recommended, it will result in a minor reduction in the size of the HTML and CSS generated.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
SCCUTFALLBACKFONT structure
Data
The name of the fallback font and the character set of that font.
Default
If this option is not set, "Arial" is used as the default fallback font.
typedef struct
{
VTLPVOID pName;
VTWORD wType;
} SCCUTFALLBACKFONT, * LPSCCUTFALLBACKFONT;
Parameters
pName: Points to the name of the font. The font name may be up to SCCUT_MAXFALLBACKFONTLEN characters in length including the NULL terminator.
wType: Specifies if the string pointed to by pName is string of single or double-byte characters. To specify the fallback font name with a single-byte character string, set wType to SCCEX_FALLBACKFONT_SINGLEBYTE. Set wType to SCCEX_FALLBACKFONT_DOUBLEBYTE to specify the font name with a double-byte character string.
This option is used to turn off specified font-related markup in the output. Naturally, if the requested output flavor or other option settings prevent markup of the specified type from being written, this option cannot be used to turn it back on. However, specifying the size, color and font face of characters may all be suppressed by bitwise OR-ing together the appropriate combination of flags in this option.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
DWORD
Data
Zero or more of the following flags bitwise OR-ed together:
SCCEX_FONTFLAGS_SUPPRESSSIZE: Turns off any character-sizing information supported in the output flavor. As an example, this flag could be useful when exporting presentation files where the author specified a very large font.
SCCEX_FONTFLAGS_SUPPRESSCOLOR: Suppresses specifying the color of text. This is particularly useful for exports of documents containing white text.
SCCEX_FONTFLAGS_SUPPRESSFACE: Prevents the technology from requesting a specific font (e.g. "Arial", "Courier", etc.) name for text. This can be useful if the template author feels that the original document font is not likely to be available to those who are viewing the converted document.
Default
0: No font information is suppressed.
Turning this option on causes the technology to generate list numbers and/or bullets as needed rather than using list markup tags. While this violates the spirit of what markup languages should do, it does cause the browsers to render the lists in a way that is more faithful to the original look of the document. An example of a list that does not view well with this option turned off is the following:
This is an example of how today's most popular browsers would render the preceding list:
This is due to the way browsers render <li> tags. The HTML standards currently do not allow any way to specify outline style list numbering.
One limitation when using this option is that standard list indentation may not be possible due to the limits of the selected output HTML flavor. At this time, only the HTML flavors where CSS is available support the kind of hanging indents normally associated with lists.
If a bullet character needs to be generated, Unicode character 0x2022 will be used. Note that many character sets do not contain this character, so the unmappable character ("*") would be used in that case.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Data
One of the following values:
TRUE: Generate list item numbers and bullets.
FALSE: Use list markup tags.
Default
FALSE
Options related to grids have no effect on the output unless a template that has been enabled with the {## unit} template macro is in use.
This option allows the developer to specify how the "previous" and "next" relationships will work between grids. As such, it is only useful when a grid-enabled template has been selected with the SCCOPT_EX_TEMPLATE option.
Setting this option to SCCEX_GRIDADVANCE_ACROSS causes the grids.next.body template element to traverse the input spreadsheet or database by rows:
Setting this option to SCCEX_GRIDADVANCE_DOWN causes the grids.next.body template element to traverse the input spreadsheet or database by columns:
This option has no effect on up/down or left/right navigation.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
One of the following values:
SCCEX_GRIDADVANCE_ACROSS: To traverse by rows.
SCCEX_GRIDADVANCE_DOWN: To traverse by columns.
Default
SCCEX_GRIDADVANCE_DOWN
Options related to grids have no effect on the output unless a template that has been enabled with the {## unit} template macro is in use.
This option allows the developer to specify the number of columns that each template "grid" (applicable only to spreadsheet or database files) should contain. As such, it is only useful when a grid-enabled template has been selected with the SCCOPT_EX_TEMPLATE option.
Setting this option to zero ("0") means that no limit is placed on the number of columns in the grid. However, the settings of the SCCOPT_EX_PAGESIZE, SCCOPT_EX_GRIDCOLS and SCCOPT_EX_GRIDROWS options must all be taken into account when determining the actual dimensions of the grids used during an export. The following table describes the interaction of these options when a template is using grids:
Table B-1 Determining Grid Dimensions
| Grid Row/Col Value | Page Size is 0 | Page Size is not 0 |
|---|---|---|
|
Grid Rows and Grid Cols are both 0. |
The entire spreadsheet is exported. |
The grid size is determined based on the Page Size. |
|
Grid Rows is 0. Grid Cols is not 0 or the default value. |
The table is broken into grids that are Grid Cols wide. Each grid contains all rows. |
The number of rows in the grid are determined by the Page Size. |
|
Grid Rows is not 0 or the default value. Grid Cols is 0. |
The table is broken into grids that are Grid Rows wide. Each grid contains all columns. |
The number of columns in the grid are determined by the Page Size. |
|
Grid Rows and Grid Cols are both not set to 0 or their default values. |
The table is broken into grids of the requested size. |
The table is broken into grids of the requested size. |
|
Grid Rows and Grid Cols are both set to their default values. |
The table is broken into grids of the default size. |
The table is broken into grids of the default size. |
Also note that once the grid size has been established for a sheet in a spreadsheet or database, the sheet cannot be re-exported with different grid dimensions. The sheet may be re-exported, however, if grids are disabled using sections.current.body.
Size calculations are performed using approximations. It is expected that each cell in the grid will contain roughly 10 characters of content. Therefore, the number of cells in the grid will be roughly the page size divided by 10. Setting the SCCOPT_EX_PAGESIZE option will not cause content to be truncated if it exceeds the 10 characters of content expected in a given cell. Note that the pageSize option is never used to force a grid to break into pages. Thus, once the grid dimensions have been established, no page breaking is performed on the grid.
The default value for this option was chosen to prevent problems with large spreadsheets, which can consume conversion time while creating unmanageable output. Together with the default grid rows option value, the default grid dimensions represent the largest table size HTML Export can produce that will not result in browsers locking up when they try to read the file.
The solution to this large spreadsheet problem depends on whether or not page breaking is in effect:
If page breaking is being used, use the maxreps attribute of the {## repeat} macro to prevent large files from becoming unmanageable.
If page breaking is NOT being used, spreadsheets should be exported by inserting only the first grid of the spreadsheet (grids.1.body). Don't use a {## repeat} loop to get all the grids. Test for the existence of a second grid (grids.2.body). If this grid exists, then have the template write out a message indicating that the spreadsheet's contents were truncated on export.
Implementing support for spreadsheets in this manner rather than by inserting sections.current.body improves performance only when outputting very large spreadsheets. In these special cases, only the first grid is exported, resulting in significant performance savings. This savings also has the side benefit of producing an output file that most Web browsers will have little trouble displaying.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
Number of columns in the grid. Use "0" (zero) to not limit the number of columns in the grid.
Default
EX_GRIDCOLS_DEFAULT: The default value for this setting is currently 100, but it is subject to change.
Options related to grids have no effect on the output unless a template that has been enabled with the {## unit} template macro is in use.
This option allows the developer to specify the number of rows that each template "grid" (applicable only to spreadsheet or database files) should contain. As such, it is only useful when a grid-enabled template has been selected with the SCCOPT_EX_TEMPLATE option.
Setting this option to zero ("0") means that no limit is placed on the number of rows in the grid. However, the settings of the SCCOPT_EX_PAGESIZE, SCCOPT_EX_GRIDCOLS and SCCOPT_EX_GRIDROWS options must all be taken into account when determining the actual dimensions of the grids used during an export.
Also note that once the grid size has been established for a sheet in a spreadsheet or database, the sheet cannot be re-exported with different grid dimensions. The sheet may be re-exported, however, if grids are disabled using sections.current.body.
Size calculations are performed using approximations. It is expected that each cell in the grid will contain roughly 10 characters of content. Therefore, the number of cells in the grid will be roughly the page size divided by 10. Setting the pageSize option will not cause content to be truncated if it exceeds the 10 characters of content expected in a given cell. Note that the pageSize option is never used to force a grid to break into pages. Thus, once the grid dimensions have been established, no page breaking is performed on the grid.
The default value for this option was chosen to prevent problems with large spreadsheets, which can consume conversion time while creating unmanageable output. Together with the default grid columns option value, the default grid dimensions represent the largest table size HTML Export can produce that will not result in browsers locking up when they try to read the file.
The solution to this large spreadsheet problem depends on whether or not page/deck breaking is in effect:
If page breaking is being used, use the maxreps attribute of the {## repeat} macro to prevent large files from becoming unmanageable.
If page breaking is NOT being used, spreadsheets should be exported by inserting only the first grid of the spreadsheet (grids.1.body). Don't use a {## repeat} loop to get all the grids. Test for the existence of a second grid (grids.2.body). If this grid exists, then have the template write out a message indicating that the spreadsheet's contents were truncated on export.
Implementing support for spreadsheets in this manner rather than by inserting sections.current.body improves performance only when inputting very large spreadsheets. In these special cases, only the first grid is exported, resulting in significant performance savings. This savings also has the side benefit of producing an output file that most Web browsers will have little trouble displaying.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
Number of rows in the grid. Use "0" (zero) to not limit the number of rows in the grid.
Default
EX_GRIDROWS_DEFAULT: The default value for this setting is currently 5000, but it is subject to change.
Options related to grids have no effect on the output unless a template that has been enabled with the {## unit} template macro is in use.
This option allows the developer to specify how the "previous" and "next" relationships will work between grids at the edges of the spreadsheet or database. As such, it is only useful when a grid-enabled template has been selected with the SCCOPT_EX_TEMPLATE option.
This option is best explained by example. Consider a spreadsheet that has been broken into 9 grids by HTML Export as follows:
If this option is set to TRUE, then the grids.next.body value after Grid 3 will be Grid 4. Likewise, the grids.previous.body value before Grid 4 will be Grid 3.
If this option is set to FALSE, then the grids.next.body after Grid 3 will not exist as far as template navigation is concerned. Likewise, the grids.previous.body before Grid 4 will not exist as far as template navigation is concerned.
In other words, this option specifies whether the "previous" and "next" relationships "wrap" at the edges of the spreadsheet or database.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
TRUE: To continue past the edge of the spreadsheet.
FALSE: To stop at the edge of the spreadsheet.
Default
TRUE
Tab support is available by setting this option to TRUE. When active, this option uses JavaScript to calculate tab stops and position blocks of text accordingly. Potential side effects of this include delays in loading the pages in the browser and seeing the text initially with no whitespace at all followed by a pause and then all of the tabs popping into place. In addition, this support is limited to only left tabs.
In order to take advantage of this option the following additional steps must be taken:
The template must contain a <script> tag. Something similar to the following code fragment is recommended:
{## if element=pragma.jsfile}
<script language="Javascript1.2" src="{## insert
element=pragma.jsfile}"></script>
{## /if}
The template must also run the DoTabStops routine in the <body> of the HTML. A span tag used to define the value of oneinch should follow this. Something similar to the following code snippet is recommended to accomplish this:
{## if element=pragma.jsfile}
<body onload="DoTabStops()">
<span id="oneinch" style="width: 1in"></span>
{## else}
<body>
{## /if}
A flavor of HTML that supports CSS must be used.
The user's browser must support JavaScript and this support must be enabled.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Data
One of the following values:
TRUE: Use JavaScript to create tabs.
FALSE: No tab support.
Default
FALSE
This option sets a suggested page size for the output generated. This means that the text of the document is broken up into "pages" of approximately the requested size. Each page is stored as a separate output file.
This feature is particularly useful when converting documents that are poorly structured. Many documents lack the kind of style information HTML Export normally uses to break the document into pieces based on things like headings. By setting this option, the exported document can be presented as a set of more manageable pieces rather than a single giant output file. It is also useful with documents that are structured but have large pieces in the structure.
If page breaking is activated (set to a non-zero value), HTML Export will buffer the entire output document in memory during conversion. Conversion times and memory requirements will increase accordingly in this case.
The size specified by this option is given in characters of text. Only text inserted from the input document is counted in the page size. Thus, "as is" text from the template is not counted against the page size. Also, markup tags are not counted in the page size. In addition, some template inserts are normally used as attributes to markup tags, and as such they are not counted in page size calculations no matter how they are actually used. Those template inserts are:
pragma.charset
pragma.jsfile
pragma.cssfilename
sections.x.itemnum
sections.x.reflink
A page size of zero ("0") indicates that this option is turned off and no page breaking is done.
When this option is turned on, the page breaking rules are as follows:
Hard page breaks in the document always trigger a page break. Soft page breaks are ignored.
A page break may be specified in the template with the {## unit break} macro.
A page boundary will never be created in the middle of a paragraph. As many paragraphs as possible will be written without exceeding the requested page size. Page sizes are not hard limits on content however. One situation where the page size could be exceeded would be if a single paragraph exceeds the page size.
When grid-enabled templates are in use, the exported grids are not broken based on the setting of this option. However, this option may affect the size of grids generated. FOr more information, see Section B.1.4.5, "SCCOPT_EX_GRIDCOLS," or Section B.1.4.6, "SCCOPT_EX_GRIDROWS."
Use of this option will not cause the contents of cells within a grid to be truncated.
When grids are not in effect, spreadsheets and databases will be broken based on page size. For these section types, checks for page breaks will be made after each full row from the spreadsheet or database is written.
It is up to the template author to then connect these pieces with the appropriate links. In order to use this option, the template must be equipped to use the {## unit} syntax.
Note that templates enabled with the {## unit} syntax may be mixed with templates that do not contain {## unit} macros. In this case, page breaking will only occur in the template that is enabled with {## unit} macros. An example of where this would be desirable is a "table of contents" template that uses two sub templates to each fill in the contents of a frame. The frame containing the actual table of contents could avoid being broken into pages by not containing any {## unit} macros. The frame containing the actual document contents could then support paging by using {## unit} macros.
Handle Types
VTHDOC, VTHEXPORT
Data Type
VTDWORD
Data
Approximate page size in characters.
Default
0: No page size limit.
Most browsers support flowing text around images. Unfortunately, even the most popular browsers also have bugs in their support for this feature that occasionally result in document elements overlapping. This option allows users of HTML Export to choose if they would rather have text flowing around graphics or if they are willing to sacrifice that feature in order to prevent browser overlap bugs.
When this option is turned on (set to TRUE), HTML Export prevents browsers from causing graphic overlap problems by surrounding all <img> tags with <div> tags. The overlap problems occur most frequently when the browser is displaying a document that has a mix of left- and right-aligned graphics in close proximity to each other. Resizing the browser window horizontally will sometimes expose this problem if it does not appear initially.
Because these browser bugs are infrequently seen, this option is turned off (set to FALSE) by default. However, setting this option to FALSE does not guarantee that text will be able to flow around graphics in the browser the same way it does in the original document. There are two problems which can prevent this from occurring.
The first problem is that when objects are placed using positional frames. Unfortunately, most new word processing formats do this automatically. When positional frames are used, each object exists in its own frame. HTML Export converts each frame as a single paragraph. Therefore, the objects are written one after the other even if they were originally placed side by side in the source document.
The second problem is associated with image alignment. For some images, HTML Export is unable to obtain the alignment of the image, so the alignment of the paragraph it is contained in is used instead. The reason HTML Export uses this alignment, which is not necessarily 100% correct, is because without adding "align=" in the <img> tag, text does not wrap around images in browsers.
Also note that setting this option to FALSE will have no effect if the SCCEX_CFLAG_STRICTDTD flag of the SCCOPT_EX_COMPLIANCEFLAGS option is set. This is because <div> tags are not allowed inside <p> tags, so HTML Export cannot use <div> tags to prevent graphics from overlapping.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Data
TRUE: Allow text flow around graphics.
FALSE: Prevent browser image overlap problems.
Default
FALSE
This option allows the developer to specify the template file that the technology uses to generate its output.
There are two ways to specify the template. One method is to set the SCCOPT_EX_TEMPLATE option with DASetOption. The other is to set it using DASetFileSpecOption. The second method is for use with redirected IO and/or Unicode with template files. Developers should use DASetOption or DASetFileSpecOption to set this option, but not both. The following two sections describe both methods.
You can use DASetOption to specify the template.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
This is the size of the buffer containing a NULL-terminated string.
Data
A complete path to the template file in the local file system or a pointer to a developer-defined data structure to be used for redirected IO.
Default
If no template file is specified, a standard template is used.
You can use DASetFileSpecOption to specify the template.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Parameters
dwSpecType: The spec type of the file. Should be set to one of the valid spec types.
pSpec: File location specification.
Default
If no template is specified, a standard template is used.
This section pertains to compression options.
This option can disable access to any files using JPEG compression, such as JPG graphic files or TIFF files using JPEG compression, or files with embedded JPEG graphics. Attempts to read or write such files when this option is enabled will fail and return the error SCCERR_UNSUPPORTEDCOMPRESSION if the entire file is JPEG compressed, and grey boxes for embedded JPEG-compressed graphics.
The following is a list of file types affected when this option is disabled:
JPG files
Postscript files containing JPG images
PDFs containing JPEG images
Note that the setting for this option overrides the requested output graphic format when there is a conflict. In the case of HTML Export, the output graphic type is set to FI_NONE in these situations.
Handle Types
HDOC, HEXPORT
Scope
Local
Data Type
VTDWORD
Data
SCCVW_FILTER_JPG_ENABLED: Allow access to files that use JPEG compression
SCCVW_FILTER_JPG_DISABLED: Do not allow access to files that use JPEG compression
Default
SCCVW_FILTER_JPG_ENABLED
This option can disable access to any files using Lempel-Ziv-Welch (LZW) compression, such as .GIF files, .ZIP files or self-extracting archive (.EXE) files containing "shrunk" files. Attempts to read or write such files when this option is enabled will fail and return the error SCCERR_UNSUPPORTEDCOMPRESSION if the entire file is LZW compressed, and grey boxes for embedded LZW-compressed graphics.
The following is a list of file types affected when this option is disabled:
GIF files
TIF files using LZW compression
PDF files that use internal LZW compression
TAZ and TAR archives containing files that are identified as FI_UNIXCOMP
ZIP and self-extracting archive (.EXE) files containing "shrunk" files
Postscript files using LZW compression
Although this option can disable access to files in ZIP or EXE archives stored using LZW compression, any files in such archives that were stored using any other form of compression will still be accessible.
The setting for this option overrides the requested output graphic format when there is a conflict. In the case of HTML Export, the output graphic type is set to FI_NONE in these situations.
Handle Types
HDOC, HEXPORT
Scope
Local
Data Type
VTDWORD
Data
SCCVW_FILTER_LZW_ENABLED: LZW compressed files will be read and written normally.
SCCVW_FILTER_LZW_DISABLED: LZW compressed files will not be read or written.
Default
SCCVW_FILTER_LZW_ENABLED
This section discusses graphics options.
This option allows the developer to specify interlaced or non-interlaced GIF output. Interlaced GIFs are useful when graphics are to be downloaded over slow Internet connections. They allow the browser to begin to render a low-resolution view of the graphic quickly and then increase the quality of the image as it is received. There is no real penalty for using interlaced graphics.
This option is only valid if the graphicType option is set to FI_GIF.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Data
One of the following values:
TRUE: Produce interlaced GIFs.
FALSE: Produce non-interlaced GIFs.
Default
TRUE
This is an advanced option that casual users of this technology may safely ignore. It allows a hard limit to be set for how tall in pixels an exported graphic may be. Any images taller than this limit will be resized to match the limit. It should be noted that regardless whether the SCCOPT_GRAPHIC_WIDTHLIMIT option is set or not, any resized images will preserve their original aspect ratio.
Note that this option differs from the behavior of setting the height of graphics by using HEIGHT= in a {## insert} statement in the template in two ways:
This option sets an upper limit on the image height. Images larger than this limit will be reduced to the limit value. However, images smaller than this height will not be enlarged when using this option. Setting the height using the height attribute in the template causes all non-embedded images to be reduced or enlarged to be of the specified height.
This option works for embedded images as well as non-embedded images. Setting a height using HEIGHT= in a {## insert} statement in the template causes only non-embedded images to be of the specified height.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
The maximum height of the output graphic in pixels. A value of zero is equivalent to SCCGRAPHIC_NOLIMIT, which causes this option to be ignored.
Default
SCCGRAPHIC_NOLIMIT: No absolute height limit specified.
This is an advanced option that casual users of this technology may safely ignore.
While this option is used to help compute table sizes, it is primarily a graphics option. Early browsers and versions of the HTML standard limit the specification of image sizes to dimensions in pixels. For images in particular, this is somewhat natural as GIF, JPEG, and PNG are bitmap formats whose sizes are defined in pixels. However, many of the source graphics and tables converted by HTML Export specify their size in physical units such as inches or centimeters, and there is no way for HTML Export to know how big a pixel is on the target device for the converted document. In fact, a single document may ultimately be viewed on many devices, each with a different number of pixels or dots per inch (DPI). Knowing this information can be important. If graphics are converted to be too small, image detail will be lost. Conversely, if the graphics are converted to be too large, files will take longer to download than is desired.
This option allows the user to specify the output graphics device's resolution in DPI and only applies to images whose size is specified in physical units (in/cm). For example, consider a 1" square, 100 DPI graphic that is to be rendered on a 50 DPI device (SCCOPT_GRAPHIC_OUTPUTDPI is set to 50). In this case, the size of the resulting WBMP, TIFF, BMP, JPEG, GIF, or PNG will be 50 x 50 pixels.
In addition, the special #define of SCCGRAPHIC_MAINTAIN_IMAGE_DPI, which is defined as 0, can be used to suppress any dimensional changes to an image. In other words, a 1" square, 100 DPI graphic will be converted to an image that is 100 x 100 pixels in size. This value indicates that the DPI of the output device is not important. It extracts the maximum resolution from the input image with the smallest exported image size.
Setting this option to SCCGRAPHIC_MAINTAIN_IMAGE_DPI may result in the creation of extremely large images. Be aware that there may be limitations in the system running this technology that could result in undesirably large bandwidth consumption or an error message. Additionally, an out of memory error message will be generated if system memory is insufficient to handle a particularly large image.
Also note that the SCCGRAPHIC_MAINTAIN_IMAGE_DPI setting will force the technology to use the DPI settings already present in raster images, but will use the current screen resolution as the DPI setting for any other type of input file.
For some output graphic types, there may be a discrepancy between the value set by this option and the DPI value reported by some graphics applications. The discrepancy occurs when the output format uses metric units (DPM, or dots per meter) instead of English units (DPI, or dots per inch). Depending on how the graphics application performs rounding on meters to inches conversions, the DPI value reported may be 1 unit more than expected. An example of a format which may exhibit this problem is PNG.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
The DPI to use when exporting graphic images. The maximum value allowed is SCCGRAPHIC_MAX_SANE_BITMAP_DPI, which is currently defined to be 2400 DPI.
Default
SCCGRAPHIC_DEFAULT_OUTPUT_DPI: Currently defined to be 96 dots per inch.
This option is used to set the maximum size of the exported graphic in pixels. It may be used to prevent inordinately large graphics from being converted to equally cumbersome output files, thus preventing bandwidth waste.
SCCOPT_GRAPHIC_SIZELIMIT takes precedence over all other options and settings that affect the size of a converted graphic. For example, if the template specifies image dimensions that exceed this size, those dimensions will be used only to calculate the aspect ratio of the final image. The image's dimensions will be restricted to produce a graphic no larger than this limit allows.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
The total number of pixels in the output graphic. A value of zero ("0"), which is equivalent to SCCGRAPHIC_NOLIMIT, causes this option to be ignored.
Default
SCCGRAPHIC_NOLIMIT: Option is turned off.
This option determines the method used to size graphics. The developer can choose among three methods, each of which involves some degree of trade off between the quality of the resulting image and speed of conversion.
Using the quick sizing option results in the fastest conversion of color graphics, though the quality of the converted graphic will be somewhat degraded. The smooth sizing option results in a more accurate representation of the original graphic, as it uses anti-aliasing. Antialiased images may appear smoother and can be easier to read, but rendering when this option is set will require additional processing time. The grayscale only option also uses antialiasing, but only for grayscale graphics, and the quick sizing option for any color graphics.
The smooth sizing option does not work on images which have a width or height of more than 4096 pixels.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
One of the following values:
SCCGRAPHIC_QUICKSIZING: Resize without antialiasing
SCCGRAPHIC_SMOOTHSIZING: Resize using antialiasing
SCCGRAPHIC_SMOOTHGRAYSCALESIZING: Resize using antialiasing for grayscale graphics only (no antialiasing for color graphics)
Default
SCCGRAPHIC_SMOOTHSIZING
This option allows the user to set the color used as the "transparency color" in the output graphic file. Naturally, this option is only used when the selected output graphic file format supports transparency (GIF and PNG only). If the option is not set, the default behavior is to use the same color value that the input file used as the transparency color.
Use the SCCVWRGB(r, g, b) macro to create the color value to pass to this option. The red, green and blue values are percentages of the color from 0-255 (with 255 being 100%). Note that this macro should be used to set a variable of type SCCVWCOLORREF and that variable should then be passed to the set option routine (instead of trying to use the macro as part of the set option call directly).
Since there is no way to "unset" an option once it has been set, the developer may set the option to SCCGRAPHIC_DEFAULTTRANSPARENCYCOLOR if they wish to revert to the default behavior.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
SCCVWCOLORREF
Data
An RGB color value created with the SCCVWRGB(r, g, b) macro.
Default
SCCGRAPHIC_DEFAULTTRANSPARENCYCOLOR: Use the same transparency color as the source document.
This option allows the developer to specify the format of the graphics produced by the technology.
When setting this option, remember that the JPEG file format does not support transparency.
Though the GIF file format supports transparency, it is limited to using only one of its 256 available colors to represent a transparent pixel ("index transparency").
PNG supports many types of transparency. The PNG files written by HTML Export are created so that various levels of transparency are possible for each pixel. This is achieved through the implementation of an 8-bit "alpha channel".
There is a special optimization that HTML Export can make when this option is set to FI_NONE. Some of the Outside In Viewer Technology's import filters can be optimized to ignore certain types of graphics. To take advantage of this optimization, the option must be set before EXOpenExport is called.
|
Note: SCCOPT_GRAPHIC_TYPE = FI_NONE must be set (via DASetOption) before the call to EXOpenExport. Otherwise, the SCCUT_FILTEROPTIMIZEDFORTEXT speed enhancement for the PDF filter is not set. This will result in slower exports of PDFs when graphic output is not required. |
It should be noted that unpredictable and potentially undesirable output will occur if this option is set to FI_NONE when EXOpenExport is called and the template then attempts to use the {## option} macro to turn graphics back on. Users who wish to turn graphics on and off from the template should set this option after the call to EXOpenExport.
The settings for options in Compression (see Section B.1.5, "Compression") may force an override of the value for this option.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
One of the following values:
FI_GIF: GIF graphics
FI_JPEGFIF: JPEG graphics
FI_PNG:
FI_NONE: Graphic conversion will be turned off
Default
FI_JPEGFIF
This is an advanced option that casual users of this technology may safely ignore. It allows a hard limit to be set for how wide in pixels an exported graphic may be. Any images wider than this limit will be resized to match the limit. It should be noted that regardless whether the SCCOPT_GRAPHIC_HEIGHTLIMIT option is set or not, any resized images will preserve their original aspect ratio.
Note that this option differs from the behavior of setting the width of graphics by using WIDTH= in a {## insert} statement in the template in two ways:
This option sets an upper limit on the image width. Images larger than this limit will be reduced to the limit value. However, images smaller than this width will not be enlarged when using this option. Setting the width using the width attribute in the template causes all non-embedded images to be reduced or enlarged to be of the specified width.
This option works for embedded images as well as non-embedded images. Setting a width using WIDTH= in a {## insert} statement in the template causes only non-embedded images to be of the specified width.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
The maximum width of the output graphic in pixels. A value of zero is equivalent to SCCGRAPHIC_NOLIMIT, which causes this option to be ignored.
Default
SCCGRAPHIC_NOLIMIT: No absolute width limit specified.
This option allows the developer to specify the lossyness of JPEG compression. The option is only valid if the graphicType option is set to FI_JPEGFIF.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
A value from 1 to 100, with 100 being the highest quality but the least compression, and 1 being the lowest quality but the most compression.
Default
100
This section pertains to spreadsheets and database options.
This option has been deprecated beginning with the 8.2 version of the product. Please use the SCCOPT_EX_SSDBROWCOLHEADINGS and SCCOPT_EX_SSDBBORDER options instead.
This option affects database files the same way it affects spreadsheets.
This option allows users to speed up the conversion of large, sparse spreadsheets by turning off the table borders HTML Export generates by default (TRUE is the default setting for this option). Setting this option to FALSE turns off table border generations, reducing the amount of HTML written and enabling rowspan and colspan table tag attributes so that empty cells can be skipped. For large, mostly empty spreadsheets, this can result in greatly reduced conversion time and output file size(s). The output appears in a format similar to that used by the original application when printing the file.
The default is to show borders (option set to TRUE). This prevents problems with most browsers, which tend to render the text in a way that makes adjacent cells hard to distinguish. This output appears in a browser in a format similar to that used by the original application when displaying the file on-screen.
This option must be set to the default value when the output format does not support tables.
When the option is set to FALSE, the following caveats apply:
If the spreadsheet being processed stores data by row (such as Microsoft Excel spreadsheets) rather than by column (such as Quattro files), additional optimizations are possible. The technology will use colspan to shrink the output when two or more adjacent cells in a row are empty. When two or more adjacent rows are completely empty, they are ignored and not included in the output.
Note that if there are merged cells in the input document, the technology will not produce perfectly optimized output. Instead, rowspan and colspan will not be used to compress empty cells until after the merged cells are processed.
This option disables the creation of Row and Column headings ("1", "2", "3" / "A", "B", "C").
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTBOOL
Default
TRUE
This option supersedes some of the functionality from the now discontinued SCCOPT_EX_SHOWSPREADSHEETBORDER option.
This option determines how borders will be handled for spreadsheet and database files.
There are three valid values for this option:
SCCEX_SSDBBORDERS_CREATEIFMISSING: If a CSS output flavor is in use, this forces borders to be created if none are present in the (entire) table. By default, most apps do not include borders when creating these types of files. When needed, HTML Export will generate thin borders between cells. Otherwise, the borders specified in the table are used.
Using borders makes it easier to read the output data by preventing values from running together when there is not much space between cells. This output appears in a browser in a format similar to that used by the original application when displaying the file on-screen.
The behavior of this setting matches the old default border behavior of the discontinued SCCOPT_EX_SHOWSPREADSHEETBORDER option.
If a CSS output flavor is not in use, then borders are put around all cells no matter how the input document is formatted. This is because individual cell border information may not be specified in HTML without CSS.
This is the default behavior for this option.
SCCEX_SSDBBORDERS_OFF: This setting forces the borders always to be off, regardless of borders specified in the source document. This option setting does not distinguish between CSS and non-CSS output flavors being used. Turning borders off has the following advantages:
It allows HTML Export to use optimizations that speed up the conversion of large, sparse files. It does this by enabling rowspan and colspan table tag attributes to be used to span empty cells. It also reduces the amount of HTML needed to be written for individual cells. For large, mostly empty spreadsheets, this can result in greatly reduced conversion time and output file size(s). The output appears in a format similar to that used by the original application when printing the file.
For left aligned text and data cells, a special optimization has been made to merge those cells with any empty cells on the right.
The following caveats apply to the optimization:
If the spreadsheet being processed stores data by row (such as Microsoft Excel spreadsheets with portrait page orientation) rather than by column (such as Quattro files), additional optimizations are possible. The technology will use colspan to shrink the output when two or more adjacent cells in a row are empty. When two or more adjacent rows are completely empty, the rows are skipped, and the row height of the next non-empty row is increased.
Note that if there are merged cells in the input document, the technology will not produce perfectly optimized output. Instead, colspan will not be used to compress empty cells until after the merged cells are processed.
The behavior of this option setting matches the old border behavior of the now discontinued SCCOPT_EX_SHOWSPREADSHEETBORDER option when it was set to FALSE. However, this option does not disable the creation of Row and Column headings ("1", "2", "3" / "A", "B", "C"). To do that, use the new SCCOPT_EX_SSDBROWCOLHEADINGS option.
If the current row has frames in it, we will not span those cells.
SCCEX_SSDBBORDERS_USESOURCE: If a CSS output flavor is being used, then this value sets the borders according to what is specified in the source document.
If a CSS output flavor is not in use, then borders are put around all cells no matter how the input document is formatted. This is because individual cell border information may not be specified in HTML without CSS.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
SCCEX_SSDBBORDERS_CREATEIFMISSING: Use source document borders. If no borders are in the table, automatically create borders.
SCCEX_SSDBBORDERS_OFF: Do not write any table borders.
SCCEX_SSDBBORDERS_USESOURCE: Use source document borders.
Default
SCCEX_SSDBBORDERS_CREATEIFMISSING
When this option is set to TRUE, row and column headings ("1", "2", "3" / "A", "B", "C") are included in the output for spreadsheet and database files. When set to FALSE, no row and column headings are created. The default for this option is TRUE.
This option supersedes some of the functionality from the now discontinued SCCOPT_EX_SHOWSPREADSHEETBORDER option.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
VTDWORD
Data
TRUE: Show row and column headings.
FALSE: Do not show row or column headings.
Default
TRUE
This section discusses page rendering options.
This option controls rendering of email headers.
Scope
Global
Data Type
VTDWORD
Data
One of these values:
SCCUT_WP_EMAILHEADERSTANDARD: Displays "To," "From," "Subject," "CC," "BCC," "Date Sent," and "Attachments" header fields only. The filter outputs any fields not listed above as hidden fields, so they will not display.
SCCUT_WP_EMAILHEADERALL: Displays all available email headers.
Default
SCCUT_WP_EMAILHEADERSTANDARD
This section discusses font rendering options.
This is an advanced option that casual users of HTML Export may ignore.
This option sets the font to use when the chunker-specified font is not available on the system. It is also the font used when the font in an embedding is not available on the system performing the conversion.
This option only affects the conversion of vector graphic images. It does not affect in any way the <font> tags used for text markup in the output.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
SCCVWFONTSPEC Structure
This structure is used by various options to specify a font.
SCCVWFONTSPEC is a C data structure defined in sccvw.h as follows:
typedef struct
{
VTTCHAR szFace[40];
VTWORD wHeight;
VTWORD wAttr;
VTWORD wType;
} SCCVWFONTSPEC, * LPSCCVWFONTSPEC;
Parameters
szFace: The name of the font. For example, "Helvetica Compressed." The default is "Arial", however this default is constrained by the fonts available on the system.
wHeight: Size of the font in half points. For example, a value of 24 will produce a 12-point font. This size is only applied when the font size is not known. The default is 10-point, however this default is constrained by the font sizes available on the system. Please note that this only affects the size of fonts in embedded vector images in the rare case where a default font size is not specified in the embedding.
wAttr: The attributes of the font. This parameter is used primarily by the Outside In Viewer Technology and is currently ignored by HTML Export.
wType: Should be set to 0.
This is an advanced option that casual users of HTML Export may ignore.
This option sets or gets printer font aliases according to the SCCVWFONTALIAS structure.
This option only affects the conversion of vector graphic images when the font specified in the original document is not available on the system doing the conversion. It does not affect in any way the <font> tags used for text markup in the output.
Handle Types
VTHDOC, VTHEXPORT
Scope
Local
Data Type
The SCCVWFONTALIAS structure.
This structure is used in the SCCOPT_PRINTFONTALIAS option.
SCCVWFONTALIAS is a C data structure defined in sccvw.h as follows:
typedef struct SCCVWFONTALIAS
{
VTDWORD dwSize;
VTDWORD dwAliasID;
VTDWORD dwFlags;
VTWORD szwOriginal[SCCVW_FONTNAMEMAX];
VTWORD szwAlias[SCCVW_FONTNAMEMAX];
} SCCVWFONTALIAS;
Parameters
dwSize: Must be set by the developer to sizeof(SCCVWFONTALIAS).
dwAliasID: ID of the aliasing in the current list of aliases.
dwFlags: The usage of these flags depends on whether this structure is being used with the DASetOption or DAGetOption message. It should be set to one of the following:
SCCVW_FONTALIAS_COUNT (DAGetOption)dwAliasID will be filled with the count of current font aliases for that device.
SCCVW_FONTALIAS_ALIASNAME (DASetOption): The alias of szwAlias for szwOriginal will be used when szwOriginal is not available on the device. When a font alias is added to the list, this can affect the alias count. If an alias already exists for szwOriginal, the new szwAlias will replace it.
SCCVW_FONTALIAS_ALIASNAME (DAGetOption): szwAlias will be filled if there is an alias in the alias list for the font in szwOriginal on that device.
SCCVW_FONTALIAS_GETALIASBYID (DAGetOption): szwAlias and szwOriginal will be filled by the technology for the alias in the numbered slot identified by the ID.
SCCVW_FONTALIAS_GETALIASID (DAGetOption): dwAliasID will be set for the font in szwOriginal. If none exists, the dwAliasID will be 0xFFFFFFF.
SCCVW_FONTALIAS_REMOVEALIASBYID (DASetOption): The alias in that slot will be removed if one exists. When a font alias is removed from the list, this can affect the other alias IDs.
SCCVW_FONTALIAS_REMOVEALIASBYNAME (DASetOption): The alias for the font szwOriginal will be removed from the alias list if one exists. When a font alias is removed from the list, this can affect the other alias IDs.
SCCVW_FONTALIAS_REMOVEALL (DASetOption): The alias list will be cleared out and the count will be zero.
SCCVW_FONTALIAS_USEDEFAULTS (DASetOption): This clears the existing alias list and sets it to a list of default aliases that is variable by platform.
szwOriginal: This represents the original name of a font that will be mapped when this font is not available. This name should be a Unicode string.
szwAlias: This represents the new name of a font that will be used as a replacement for the unmapped font named in szwOriginal. This name should be a Unicode string.
Data
The technology assumes the following default mappings. The first value is the szwOriginal Value, the second is the szwAlias Value.
Chicago = Arial
Geneva = Arial
New York = Times New Roman
Helvetica = Arial
Helv = Arial
times = Times New Roman
Times = Times New Roman
Tms Roman = Times New Roman
Symbol = Symbol
itc zapfdingbats = Zapfdingbats
itc zapf dingbats = Zapfdingbats
This section discusses callback options.
This is an advanced option that casual users of HTML Export may ignore.
This option is used to disable callbacks being made from HTML Export. Callbacks that are disabled will behave as if they were made and the developer had returned SCCERR_NOTHANDLED.
The option takes a VTDWORD field of flags. When the flag is set, the callback is enabled. By default, all callbacks are enabled. You can activate multiple callbacks by bitwise OR-ing them together. You can also disable multiple callbacks by bitwise &-ing the SCCEX_CALLBACKFLAG_ALLENABLED value with the one's complement of the corresponding callback flags. The following #defines are to be used for enabling the various callbacks:
| Flag | Associated Callbacks |
|---|---|
| SCCEX_CALLBACKFLAG_CREATENEWFILE | EX_CALLBACK_ID_CREATENEWFILE |
| SCCEX_CALLBACKFLAG_NEWFILEINFO | EX_CALLBACK_ID_NEWFILEINFO |
| SCCEX_CALLBACKFLAG_PROCESSLINK | EX_CALLBACK_ID_PROCESSLINK |
| SCCEX_CALLBACKFLAG_CUSTOMELEMENT | EX_CALLBACK_ID_CUSTOMELEMENTLIST
EX_CALLBACK_ID_PROCESSELEMENTSTR EX_CALLBACK_ID_PROCESSELEMENTSTR_VER2 |
| SCCEX_CALLBACKFLAG_GRAPHICEXPORTFAILURE | EX_CALLBACK_ID_GRAPHICEXPORTFAILURE |
| SCCEX_CALLBACKFLAG_OEMOUTPUT | EX_CALLBACK_ID_OEMOUTPUT
EX_CALLBACK_ID_OEMOUTPUT_VER2 |
| SCCEX_CALLBACKFLAG_ALTLINK | EX_CALLBACK_ID_ALTLINK |
| SCCEX_CALLBACKFLAG_ARCHIVE | EX_CALLBACK_ID_ENTERARCHIVE
EX_CALLBACK_ID_LEAVEARCHIVE EX_CALLBACK_ID_REFLINK |
In addition, the following two special values are available:
SCCEX_CALLBACKFLAG_ALLDISABLED: Disables the receipt of all callbacks. Additionally, bitwise OR-ing this value with one or more flags enables the corresponding callbacks. For example, SCCEX_CALLBACKFLAG_ALTLINK | SCCEX_CALLBACKFLAG_CREATENEWFILE enables the ALTLINK and CREATENEWFILE callbacks, but disables all others.
SCCEX_CALLBACKFLAG_ALLENABLED: Enables the receipt of all callbacks. Additionally, bitwise &-ing this value with the one's complement of one or more flags disables the corresponding callbacks. For example, SCCEX_CALLBACKFLAG_ALLENABLED& (~SCCEX_CALLBACKALTLINK & ~SCCEX_CALLBACKFLAG_CREATENEWFILE) disables the ALTLINK and CREATENEWFILE callbacks, but enables all others.
Handle Types
VTHDOC
Scope
Local
Data Type
VTDWORD
Data
One or more of the valid flags, bitwise OR-ed together
Default
SCCEX_CALLBACKFLAG_ALLENABLED: All callbacks are available to the developer.
This option determines the format of strings used in the callback functions. For those structures that contain a field of type BYTE or LPBYTE, a comparable structure has been added which has a similar field of type WORD or LPWORD. These structures will have the same name as the original structure, with the addition of a "W" at the end.
When this option is set to TRUE, any time a callback uses a structure with a string, it will use the new structure. Also, any strings that the callback function returns will be expected to follow the same guidelines. If the option is set to FALSE, all callbacks will use single-byte character strings.
For example, if this option is set to TRUE, and the EX_CALLBACK_ID_CREATENEWFILE callback is called, the pExportData parameter to the callback will point to an EXURLFILEIOCALLBACKDATAW structure. If the option is set to FALSE, the pCommandOrInfoData parameter will point to an EXURLFILEIOCALLBACKDATA structure.
This option should be set before EXOpenExport is called.
Handle Types
VTHDOC
Scope
Local
Data Type
VTBOOL
Data
One of the following values:
TRUE: Use Unicode strings in callbacks.
FALSE: Do not use Unicode strings in callbacks.
Default
FALSE
This section pertains to file system options.
This set of three options allows the user to adjust buffer sizes to tailor memory usage to the machine's ability. The numbers specified in these options are in kilobytes. These are advanced options that casual users of HTML Export may ignore.
Handle Type
NULL, VTHDOC
Scope
Global
Data Type
SCCBUFFEROPTIONS structure
Data
A buffer options structure
typedef struct SCCBUFFEROPTIONStag
{
VTDWORD dwReadBufferSize; /* size of the I/O Read buffer
in KB */
VTDWORD dwMMapBufferSize; /* maximum size for the I/O
Memory Map buffer in KB */
VTDWORD dwTempBufferSize; /* maximum size for the memory-
mapped temp files in KB */
VTDWORD dwFlags; /* use flags */
} SCCBUFFEROPTIONS, *PSCCBUFFEROPTIONS;
Parameters
dwReadBufferSize: Used to define the number of bytes that will read from disk into memory at any given time. Once the buffer has data, further file reads will proceed within the buffer until the end of the buffer is reached, at which point the buffer will again be filled from the disk. This can lead to performance improvements in many file formats, regardless of the size of the document.
dwMMapBufferSize: Used to define a maximum size that a document can be and use a memory-mapped I/O model. In this situation, the entire file is read from disk into memory and all further I/O is performed on the data in memory. This can lead to significantly improved performance, but note that either the entire file can be read into memory, or it cannot. If both of these buffers are set, then if the file is smaller than the dwMMapBufferSize, the entire file will be read into memory; if not, it will be read in blocks defined by the dwReadBufferSize.
dwTempBufferSize: The maximum size that a temporary file can occupy in memory before being written to disk as a physical file. Storing temporary files in memory can boost performance on archives, files that have embedded objects or attachments. If set to 0, all temporary files will be written to disk.
dwFlags
SCCBUFOPT_SET_READBUFSIZE 1
SCCBUFOPT_SET_MMAPBUFSIZE 2
SCCBUFOPT_SET_TEMPBUFSIZE 4
To set any of the three buffer sizes, set the corresponding flag while calling dwSetOption.
Default
The default settings for these options are:
#define SCCBUFOPT_DEFAULT_READBUFSIZE 2: A 2KB read buffer.
#define SCCBUFOPT_DEFAULT_MMAPBUFSIZE 8192: An 8MB memory-map size.
#define SCCBUFOPT_DEFAULT_TEMPBUFSIZE 2048: A 2MB temp-file limit.
Minimum and maximum sizes for each are:
SCCBUFOPT_MIN_READBUFSIZE 1: Read one Kbyte at a time.
SCCBUFOPT_MIN_MMAPBUFSIZE 0: Don't use memory-mapped input.
SCCBUFOPT_MIN_TEMPBUFSIZE 0: Don't use memory temp files
SCCBUFOPT_MAX_READBUFSIZE 0x003fffff, SCCBUFOPT_MAX_MMAPBUFSIZE 0x003fffff, SCCBUFOPT_MAX_TEMPBUFSIZE 0x003fffff: These maximums correspond to the largest file size possible under the 4GB DWORD limit.
From time to time, the technology needs to create one or more temporary files. This option sets the directory to be used for those files.
It is recommended that this option be set as part of a system to clean up temporary files left behind in the event of abnormal program termination. By using this option with code to delete files older than a predefined time limit, the OEM can help to ensure that the number of temporary files does not grow without limit.
Note:
This option will be ignored if SCCOPT_REDIRECTTEMPFILE is set.Handle Types
NULL, VTHDOC
Scope
Global
Data Type
SCCUTTEMPDIRSPEC structure
This structure is used in the SCCOPT_TEMPDIR option.
SCCUTTEMPDIRSPEC is a C data structure defined in sccvw.h as follows:
typedef struct SCCUTTEMPDIRSPEC
{
VTDWORD dwSize;
VTDWORD dwSpecType;
VTBYTE szTempDirName[SCCUT_FILENAMEMAX];
} SCCUTTEMPDIRSPEC, * LPSCCUTTEMPDIRSPEC;
There is a limitation in the current release. dwSpecType describes the contents of szTempDirName. Together, dwSpecType and szTempDirName describe the location of the source file. The only dwSpecType values supported at this time are:
IOTYPE_ANSIPATH: Windows only. szTempDirName points to a NULL-terminated full path name using the ANSI character set and FAT 8.3 (Win16) or NTFS (Win32 and Win64) file name conventions.
IOTYPE_UNICODEPATH: Windows only. szTempDirName points to a NULL-terminated full path name using the Unicode character set and NTFS file name conventions. Note that the length of the path name is limited to SCCUT_FILENAMEMAX bytes, or (SCCUT_FILENAMEMAX / 2) double-byte Unicode characters.
IOTYPE_UNIXPATH: X Windows on UNIX platforms only. szTempDirName points to a NULL-terminated full path name using the system default character set and UNIX path conventions.
Specifically not supported at this time is IOTYPE_REDIRECT.
Users should also note that temporary files created by the technology are not subject to callbacks (such as EX_CALLBACK_ID_CREATENEWFILE) normally made when files are created.
Parameters
dwSize: Set to sizeof(SCCUTTEMPDIRSPEC).
dwSpecType: IOTYPE_ANSIPATH, IOTYPE_UNICODEPATH, or IOTYPE_UNIXPATH
szTempDirName: The path to the directory to use for the temporary files. Note that if all SCCUT_FILENAMEMAX bytes in the buffer are filled, there will not be space left for file names.
Default
The system default directory for temporary files. On UNIX systems, this is the value of environment variable $TMP. On Windows systems, it is the value of environment variable %TMP%.
This option determines the maximum amount of memory that the chunker may use to store the document's data, from 4 MB to 1 GB. The more memory the chunker has available to it, the less often it needs to re-read data from the document.
Handle Types
NULL, VTHDOC
Scope
Global
Data Type
VTDWORD
Parameters
SCCDOCUMENTMEMORYMODE_SMALLEST 1 - 4MB
SCCDOCUMENTMEMORYMODE_SMALL 2 - 16MB
SCCDOCUMENTMEMORYMODE_MEDIUM 3 - 64MB
SCCDOCUMENTMEMORYMODE_LARGE 4 - 256MB
SCCDOCUMENTMEMORYMODE_LARGEST 5 - 1 GB
Default
SCCDOCUMENTMEMORYMODE_SMALL 2 - 16MB
This option is set when the developer wants to use redirected IO to completely take over responsibility for the low level IO calls of the temp file.
Handle Types
NULL, VTHDOC
Scope
Global (not persistent)
Data Type
VTLPVOID: pCallbackFunc
Function pointer of the redirect IO callback.
Redirect call back function:
typedef
{
VTDWORD (* REDIRECTTEMPFILECALLBACKPROC)
(HIOFILE *phFile,
VTVOID *pSpec,
VTDWORD dwFileFlags);
There is another option to handle the temp directory, SCCOPT_TEMPDIR. Only one of these two can be set by the developer. The SCCOPT_TEMPDIR option will be ignored if SCCOPT_REDIRECTTEMPFILE is set. These files may be safely deleted when the Close function is called.
The options discussed in this section are only settable via the {## option} macro in the template.
Support for this option is limited to MIcrosoft Word documents.
Some input documents contain links. Template authors may have a preference for how the browser should select which frame or window to open those source document links in. This option allows the template author to do so by specifying a value to use for the target attribute of the links HTML Export generates in these cases. This single target value will be applied to all such links encountered in the source document. It does not affect the links generated by HTML Export for navigation generated because of template macros.
If this option is not set, then no target attribute will be included in links from the source document.
The value of the target attribute is expected to be able to be inserted by HTML Export directly into the output of the conversion. Under some circumstances, however, HTML Export may need to perform character mapping from the template to the output character set:
Templates written in a SBCS for conversions to DBCS will pad the text to form WORD sized characters, but will not perform any character mapping. In the unlikely event that this poses a problem, users should write their templates in UTF-8 or Unicode.
Templates written in Unicode for conversions will do character mapping to the appropriate output character set.
For example, consider a document that contains a link to www.outsideinsdk.com. The template author wishes to change the browser's default behavior from opening the link in the current window to opening the link in a new window. Therefore, the template writer sets this option to _blank with the following line in the template:
{## option EX_LINKTARGET=_blank}
HTML Export will then generate the following link to the Oracle web page when the document is converted (HTML related to text formatting has been removed for clarity):
<a href="http://www.outsideinsdk.com/" target="_blank">www.outsideinsdk.com</a>
The following are valid values for the target= attribute in HTML:
_blank: The user agent should load the designated document in a new, unnamed window.
_self: The user agent should load the document in the same frame as the element that refers to this target.
_parent: The user agent should load the document into the immediate FRAMESET parent of the current frame. This value is equivalent to _self if the current frame has no parent.
_top: The user agent should load the document into the full, original window (thus canceling all other frames). This value is equivalent to _self if the current frame has no parent.
The default is for this option not to be set. In that case, no target= attribute will be generated for links from the source document.
Link target attribute values may be specified in both the source document and in the template via the EX_LINKTARGET template-only option. This option determines how to resolve such conflicts.
The option has two settings (neither is case-sensitive):
Fallback: The value specified in the EX_LINKTARGET option is a fallback to use when the source document does not specify a link target attribute value. This is the default setting for this option if it is not set.
Override: The value specified in the EX_LINKTARGET option will always be used, overriding any link target attribute value(s) specified by the source document.
Sample usage:
{## option EX_LINKTARGET="_self"}
{## option EX_LINKTARGETOVERIDE="Override"}
This option is ignored if the EX_LINKTARGET option has not been set.
The default for this option is to not be set. In that case, the value specified by the EX_LINKTARGET option is used as a fallback.
As the HTML Export product family continues to evolve, it has sometimes become necessary to change options that are no longer supported. In addition, the names of some of the options and option values have also been changed to help create a more consistent API. In all cases, the old names and options will continue to compile. Old options will simply cease to have an effect on output. Old option and value names are mapped to the new names. OEMs are encouraged to use the new names wherever possible.
The following options have been discontinued. For the foreseeable future, HTML Export will continue to support calls to set these options. While setting these options will not cause an error, they will have no effect on the output produced by HTML Export.
Introduced in the 1.1.0 release. The option has been discontinued due to performance enhancements in the HTML Export 1.1.1 release that made the fast, but lower quality setting for this option unnecessary. Superior quality palettes are now generated so quickly that there is no need to generate lower quality palettes.
While the old option names will continue to be supported for the foreseeable future, OEMs are encouraged to use the new names for options and their values from this point forward. The following is a list of old names and their new counterparts:
| Old Name | New Name |
|---|---|
| SCCOPT_CHARBYTEORDER | SCCOPT_EX_CHARBYTEORDER |
| SCCOPT_GRAPHICSIZEMETHOD | SCCOPT_GRAPHIC_SIZEMETHOD |
| SCCOPT_HTML_FLAGS | SCCOPT_EX_COMPLIANCEFLAGS |
| SCCOPT_HTML_FLAVOR | SCCOPT_EX_FLAVOR |
| SCCOPT_HTML_GENBULLETSANDNUMS | SCCOPT_EX_GENBULLETSANDNUMS |
| SCCOPT_HTML_GRAPHICTYPE | SCCOPT_GRAPHIC_TYPE |
| SCCOPT_HTML_OUTPUTCHARACTERSET | SCCOPT_EX_OUTPUTCHARACTERSET |
| SCCOPT_HTML_SIMPLESTYLENAMES | SCCOPT_EX_SIMPLESTYLENAMES |
| SCCOPT_HTML_TEMPLATE | SCCOPT_EX_TEMPLATE |
| SCCOPT_NO_SOURCEFORMATTING | SCCOPT_EX_NOSOURCEFORMATTING |
| SCCOPT_OUTPUTCHARACTERSET | SCCOPT_EX_OUTPUTCHARACTERSET |
| SCCOPT_SIMPLESTYLENAMES | SCCOPT_EX_SIMPLESTYLENAMES |
| SCCOPT_UNICODECALLBACKSTR | SCCOPT_EX_UNICODECALLBACKSTR |
The following #define names have been changed. The old #defines will continue to be supported for the foreseeable future. However, OEMs are encouraged to use the new names for options and their values from this point forward. What follows is a list of old names and their new counterparts:
| Old Name | New Name |
|---|---|
| SCCHTML_FLAG_STRICTDTD | SCCEX_CFLAG_STRICTDTD |
| SCCHTML_FLAG_WELLFORMED | SCCEX_CFLAG_WELLFORMED |
| SCCOPT_CHARBYTEORDER_BIGENDIAN | SCCEX_CHARBYTEORDER_BIGENDIAN |
| SCCOPT_CHARBYTEORDER_LITTLEENDIAN | SCCEX_CHARBYTEORDER_LITTLEENDIAN |
| SCCOPT_CHARBYTEORDER_TEMPLATE | SCCEX_CHARBYTEORDER_TEMPLATE |
| SCCOPT_EX_FALLBACKFONT_SINGLEBYTE | SCCEX_FALLBACKFONT_SINGLEBYTE |
| SCCOPT_EX_FALLBACKFONT_DOUBLEBYTE | SCCEX_FALLBACKFONT_DOUBLEBYTE |
| SCCHTML_FLAVOR_GENERIC | SCCEX_FLAVOR_GENERICHTML |
| SCCHTML_FLAVOR_20 | SCCEX_FLAVOR_HTML20 |
| SCCHTML_FLAVOR_30 | SCCEX_FLAVOR_HTML30 |
| SCCHTML_FLAVOR_40 | SCCEX_FLAVOR_HTML40 |
| SCCHTML_FLAVOR_MO21 | SCCEX_FLAVOR_MO21 |
| SCCHTML_FLAVOR_NS11 | SCCEX_FLAVOR_NS11 |
| SCCHTML_FLAVOR_NS20 | SCCEX_FLAVOR_NS20 |
| SCCHTML_FLAVOR_NS30 | SCCEX_FLAVOR_NS30 |
| SCCHTML_FLAVOR_NS40 | SCCEX_FLAVOR_NS40 |
| SCCHTML_FLAVOR_MS15 | SCCEX_FLAVOR_MS15 |
| SCCHTML_FLAVOR_MS20 | SCCEX_FLAVOR_MS20 |
| SCCHTML_FLAVOR_MS30 | SCCEX_FLAVOR_MS30 |
| SCCHTML_FLAVOR_MS40 | SCCEX_FLAVOR_MS40 |
These options are available to the developer when using the export engine through the Transformation Server API.
This section details the Web Services implementation of options in Transformation Server. However, there are links to API-specific information for the C and JAVA client interfaces to the technology within each of the following sections.
An option is defined by an identifier and an associated value. The identifier (hOptions) indicates what particular option is being specified. The option value data must be in a form that conforms to the set of supported data types.
Note that it is not necessarily an error to specify options that are not understood by the export engine, but some transformation engines may require that certain options be specified.
Of course some options are more important than others. Casual users of this API should focus on the following (in rough order of importance):
Setting the Output Flavor (Section B.2.3.6, "flavor")
Setting the Graphic Type (Section B.2.7.7, "graphicType")
Setting the Output Character Set (Section B.2.2.3, "outputCharacterSet")
This section discusses character mapping options.
This option is used in cases where Outside In cannot determine the character set used to encode the text of an input file. When all other means of determining the file's character set are exhausted, Outside In will assume that an input document is encoded in the character set specified by this option. This is most often used when reading plain-text files, but may also be used when reading HTML or PDF files.
When the "extended test for text" is enabled (see Section B.2.4.2, "extendedTestForText"), this option will still apply to plain-text input files that are not identified as EBCDIC or Unicode.
This option supersedes the fallbackFormat option for selecting the character set assumed for plain-text files. For backwards compatibility, use of deprecated character-set -related values is still currently supported for fallbackFormat, though internally such values will be translated into equivalent values for the defaultInputCharset. As a result, if an application were to set both options, the last such value set for either option will be the value that takes effect.
Data Type
DefaultInputCharSet
Data
The SOAP representation of the character set to use, from the values in defaultInputCharSetEnum.
This option determines the byte order of Unicode characters in the output files when Unicode is chosen as the output character set.
Data Type
CharacterByteOrderEnum
Data
One of the following values:
big-endian: Big-Endian byte ordering is common on RISC and Motorola processors. The ISO 10646 standard, the Unicode Standard and the W3C recommend Big-Endian Unicode. It also corresponds to network byte order.
little-endian: Little Endian is common on Intel processors.
template-order: This value will cause the output to use the byte ordering used in the main template file, if the template is written in Unicode. If the template is not written in Unicode, Big-Endian byte order is used.
Default
template-order
Links
C Client Implementation: OIT_CharacterByteOrderEnum
JAVA Client Implementation: CharacterByteOrderEnum
This option allows the developer to specify which character set should be used in the output file. The technology will then translate or "map" characters from the input document's character set to the output character set as needed. Naturally, export process does not translate content from one language to another. This character mapping is also clearly limited by the need for the character to be in both the input and the output character sets. If a character cannot be mapped, the character will show up in the output as the "unmappable character." The default unmappable character used is the "*" character. The character used may be changed by setting the unmappableCharacter option. If the resulting output contains an excessive number of these "*" characters, selecting a more appropriate output character set should improve the situation.
The technology reserves the right to override this option. The option will be overridden if ANSI Double-Byte Character Set (DBCS) characters are detected in the source document and a single-byte character set is chosen as the output character set. If the option is overridden, this change will affect the entire output document. The technology uses the first DBCS character set it finds in the document as the basis for its decision about which output character set to choose as its override.
Note that special character set override rules apply when the input document uses the HWP (Hangul 97) filter. For these documents, the output character set will be forced to EUC-KR unless the user has selected euc-kr, Unicode or UTF-8 output. These override rules do not apply to the HWP2 (Hangul 2002) filter, as it uses Unicode exclusively.
Source documents in Unicode will not override this option. This is especially important to remember as some important file formats store text in Unicode including Microsoft Office.
The markup standards currently supported by HTML Export limit documents to a single character set. That character set is specified in an output file using the CONTENT attribute of the <meta> tag. This limits what the technology can do with documents that have multiple character sets. In general, documents that are a mix of a single Asian language and English characters will translate correctly (although with some possible loss of non-alphanumeric characters) if the appropriate DBCS, UTF-8 or Unicode output character set is selected. This is because most DBCS character sets include the standard 7-bit Latin 1 characters. Documents that contain more than one DBCS character set or a DBCS character set and a non-English character set (such as Cyrillic) may not export with all the character glyphs intact unless Unicode or UTF-8 is used.
While the W3C recommends using Unicode, there is a downside to it at this time. Not all systems have the appropriate fonts needed for using Unicode or UTF-8. Many editors do not understand these character sets, as well. In fact, while HTML Export can read Unicode source documents, it cannot read UTF-8 source documents. In addition, there are some differences in the way browsers interpret the byte order of 2-byte Unicode characters. For additional details about the byte ordering issue, see Section B.2.2.2, "characterByteOrder."
An additional HTML browser idiosyncrasy affects the Netscape 4.0 – 6.0 browsers. While these browsers properly render Unicode HTML, they seem to be unable to read .css files that are written in Unicode. For this reason, if the output character set is Unicode and the HTML flavor (described in Section B.2.3.6, "flavor") being generated is Netscape 4.0 or the common 4.0 flavor, the associated .css file will be written in UTF-8.
In order for HTML Export to correctly place the character set into the output file it generates, all templates should include a statement that uses the {## insert} macro to insert the character set into the document, as in the following example:
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset={## insert element=pragma.charset}" />
If the template does not include this line, the user may have to manually select the correct character set in the user's browser.
Data Type
CharacterSetEnum
Data
One of the following values:
| Value | Text used in <META…> tag | Description |
|---|---|---|
| ISO-8859-1 | iso-8859-1 | Latin-1 - this is a subset of Windows 1252 |
| ISO-8859-2 | iso-8859-2 | Latin-2 |
| ISO-8859-3 | iso-8859-3 | Latin-3 |
| ISO-8859-4 | iso-8859-4 | Latin-4 |
| ISO-8859-5 | iso-8859-5 | Cyrillic |
| ISO-8859-6 | iso-8859-6 | Arabic |
| ISO-8859-7 | iso-8859-7 | Greek |
| ISO-8859-8 | iso-8859-8 | Hebrew |
| ISO-8859-9 | iso-8859-9 | Turkish |
| x-Mac-roman | x-mac-roman | Mac Roman |
| x-Mac-ce | x-mac-ce | Mac CE |
| x-Mac-Greek | x-mac-greek | Mac Greek |
| x-Mac-Cyrillic | x-mac-cyrillic | Mac Cyrillic |
| x-Mac-Turkish | x-mac-turkish | Mac Turkish |
| GB2312 | gb2312 | Simplified Chinese |
| Big5 | big5 | Traditional Chinese |
| Shift_JIS | Shift_JIS | Japanese |
| KOI8-R | koi8-r | Russian |
| windows-1250 | x-cp1250 | Eastern Europe |
| windows-1251 | x-cp1251 | Cyrillic |
| windows-1252 | windows-1252 | Western - Windows 1252 |
| windows-1253 | windows-1253 | Greek |
| windows-1254 | windows-1254 | Turkish |
| windows-1255 | windows-1255 | Hebrew |
| windows-1256 | windows-1256 | Arabic |
| windows-1257 | windows-1257 | Baltic |
| EUC-KR | euc-kr | Korean Hangul KSC 5601-1987 Wansung |
| EUC-JP | euc-jp | Japanese EUC |
| ISO-2022-JP | iso-2022-jp | JIS (Japanese) |
| windows-874 | windows-874 | Thai |
| UTF-8 | UTF-8 | UTF-8 (a Unicode variant) |
| ISO-10646-UCS-2 | ISO-10646 | Unicode |
Default
windows-1252
Links
C Client Implementation: TS_CharacterSetEnum
JAVA Client Implementation: CharacterSetEnum
This option selects the character used when a character cannot be found in the output character set. This option takes the Unicode value for the replacement character. It is left to the user to make sure that the selected replacement character is available in the output character set.
Note that when exporting to the 4.0 and higher flavors, HTML Export will not have any unmappable characters in its HTML. Instead, it will write the unmapped character out in &#....; notation using the decimal representation of the character's Unicode value. Newer browsers support this representation and will convert it to the appropriate character if it is available in the font being used. If the character is not available in that font, the browser's unmappable character symbol (typically a rectangular box) will be seen. Also note that there may still be unmapped characters in text rendered to graphics. This is because the graphic file is generated by HTML Export at conversion time rather than being rendered by the browser.
Care should be taken in choosing which character to use for the unmappable character. The character should be one that will create minimal confusion between those characters that were correctly mapped, and characters that were unmapped. Not only does such confusion make reading the document more difficult, it can cause additional problems as well. For example, if the unmappable character is also a character in the name of a font being used in the output, HTML Export may become unable to use that font. In general, letters and numbers make poor choices for the value of this option.
Data Type
xsd:unsignedShort
Data
The Unicode value for the character to use.
Default
0x002a = "*"
Links
C Client Implementation: XSD_unsignedShort
JAVA Client Implementation: UnsignedShort
This section discusses output options.
The option takes the form of a data structure that contains two ts:stringData structures; one for the "prev" link and one for the "next" link. These values are used in the transformation process when it is creating multiple output files that link to and from each other. The "prev" altlink is used for the link-to-previous-item in the first output file. The "next" altlink is used for the link-to-next link on the last page of output.
Data Type
AltLink
Data
The altlink option is a complexType data structure composed of ts:stringData values. The values are links to the "prev" and "next" output files.
Default
These strings are empty by default.
Links
C Client Implementation: OIT_AltLink
JAVA Client Implementation: AltLink
The setting for this option determines whether or not change tracking information in input documents will be written into the output via the <ins> and <del> HTML tags. When the option is set to false, no change tracking information will be written into the output. When set to true, the <ins> and <del> tags will be used as appropriate.
Previous versions of HTML Export included change tracking text in comments.
Data Type
xsd:boolean
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This is an advanced option that casual users of HTML Export may safely ignore.
When set, this option deletes whitespace from the output document. Two types of whitespace are removed: redundant whitespace characters and vertical whitespace. This option is intended for situations where bandwidth and screen space are limited.
The HTML standard specifies that the browser will collapse a sequence of whitespace characters into a single whitespace character. Therefore, having HTML Export remove these redundant whitespace characters has no effect on the final view of the document. Removing them benefits the document in reducing the overall size of the output files generated and thereby saves bandwidth and decreases file transmission times. While HTML Export makes an effort to remove as much redundant whitespace as possible, there will be cases where some extra spacing appears in the output.
Removing vertical whitespace, on the other hand, does affect the look of the document in the browser. When possible, HTML Export preserves vertical spacing between elements. However, when this option is set, vertical whitespace is removed, resulting in a more compact view.
Please note that the collapse white space option does not affect whitespace coming from the template.
Data Type
xsd:boolean
Data
One of the following values:
true Whitespace is removed.
false: Whitespace is left intact.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option allows the developer to force the output to be compliant with a given standard. Currently, only DTD and well-formed compliance are supported. The option takes the form of a set of bit flags for toggling the available options. Flags are off by default and are turned on by bitwise OR-ing them together.
Data Type
ComplianceEnum
Data
Any of the following flags:
strictDTD: Set to enforce strict DTD compliance in the HTML written. The resulting HTML will be well formed. This means that an XML parser can parse it. In addition, "safe" HTML tags normally written by HTML Export are turned off when this flag is set. For more information about "safe" tags, see Section B.2.3.6, "flavor."
Especially when using older HTML flavors, use of this flag somewhat diminishes the fidelity of the view of the output document compared to the original document. In addition to other changes to the output, setting this flag also has the same effect as setting the preventGraphicOverlap option to true.
This flag should not be used with the well-formed flag. If they are both set, this flag will override the well-formed flag.
Most users will probably want to use the well-formed flag instead of this flag.
well-formed: Set to force the HTML written to be well formed. This means that an XML parser can parse it. This option differs from the strictDTD flag in that it allows "safe" tags. This flag should not be used with the strictDTD flag. If they are both set, the strict DTD flag will override this flag. For most users, this flag is recommended over the use of the strictDTD flag as it produces well formed, XHTML compliant HTML without the penalties imposed by the strict DTD flag.
none: All flags turned off.
Default
none
Links
C Client Implementation: OIT_ComplianceEnum
JAVA Client Implementation: ComplianceEnum
This option controls the extraction of embedded documents in the input document. When set to extractFiles, the embedding will be extracted in its native format, allowing it to be read by the authoring application. When set to convertFiles, the embedding will be extracted as HTML. When set to ignoreFiles, the embedding will be ignored.
This option is only valid for UUE, MIME and MSG files and not for general purpose file attachments.
Data
ignoreFiles: Embeddings are skipped.
convertFiles: Embeddings are converted.
extractFiles: Embeddings are extracted in their native file format.
Default
ignoreFiles
Links
C Client Implementation: OIT_ExtractEmbeddedFilesEnum
JAVA Client Implementation: ExtractEmbeddedFilesEnum
Each Web browser forms a de facto HTML standard. This is because each browser has a unique collection of HTML tags and tag attributes it does or does not support. Thus, there are a large number of browser-based variations on the official HTML standards that are referred to here as "flavors" of HTML.
This option allows the developer to tailor the output generated to a specific browser or for a specific minimum browser. This allows HTML Export to produce the best possible rendering of the source document given the tags available in the target flavor. It also gives the OEM the ability to specify which standard their product will adhere to, rather than having that standard be dictated by HTML Export.
HTML Export currently supports a large number of flavors. While some flavors are targeted at specific browsers, other flavors are designed for a more abstract target. The "generic" and "HTML 2.0" flavors provide "lowest common denominator" flavors. The HTML produced by these flavors is very simple and should work in almost any browser. The primary difference between these two flavors is that the generic flavor supports tables and the HTML 2.0 flavor does not.
At other times, it is desirable to have the ability to create HTML that simply supports "the major x.0 and later browsers." For this purpose, there are the "greatest common denominator" flavors. They are the "3.0" and "4.0" flavors. The "3.0" flavor should be used to create HTML that will look good in Netscape Navigator 3.0 or later and in Microsoft Internet Explorer 3.0 or later. The "4.0" flavor is defined to look good in Netscape Navigator 4.0 or later and in Microsoft Internet Explorer 4.0 or later. Note that upon examining the capabilities of these browsers after the 4.0 versions, it was determined that while they offer many new features, they do not have any .html or .css extensions that are useful to HTML Export at this time.
Naturally, support for a particular HTML flavor does not mean that HTML Export will generate all the tags and tag attributes that flavor supports. There are many tags and attributes that cannot sensibly be used in an automated conversion setting. Such tags require more information about the author's intent than is available in the source document.
Exporting a document to a particular HTML flavor also does not mean that the resulting HTML will be limited to only the tags and tag attributes supported by that flavor. In many cases, HTML Export will write out extra "safe" tags to the document, unless compliance (see Section B.2.3.4, "compliance") has the strictDTD flag set. The target browser will safely ignore this extra HTML. However, should the converted document be viewed in a more sophisticated browser, this extra information will be used to produce a more accurate view of the document.
What support for a particular HTML flavor does mean is that the HTML generated will look as good as possible when viewed in the appropriate browser.
Data Type
FlavorEnum
Data
One of the following values. Note that the flavors marked with "(CSS)" indicate that the flavor in question requires the creation of a separate or embedded .css file as part of the document conversion.
| Value | Description |
|---|---|
| generic-html | General purpose, simple HTML support that should look good in any browser that supports tables. |
| html2.0 | HTML 2.0. Based on the official HTML 2.0 standard, this provides minimal HTML support and per that standard, it does not support tables. |
| html3.0 | Should look good in both Netscape Navigator 3.0 or later and Microsoft Internet Explorer 3.0 or later. |
| html4.0 | Should look good in both Netscape Navigator 4.0 or later and Microsoft Internet Explorer 4.0 or later (CSS). |
| netscape3.0 | Netscape Navigator 3.0 |
| netscape4.0 | Netscape Navigator 4.0 (CSS) |
| internetExplorer3.0 | Microsoft Internet Explorer 3.0. Note that while this flavor has limited CSS support, it does not create a separate or embedded .css file. |
| internetExplorer4.0 | Microsoft Internet Explorer 4.0 (CSS) |
Default
html4.0
Links
C Client Implementation: OIT_FlavorEnum
JAVA Client Implementation: FlavorEnum
This is an advanced option that casual users may safely ignore.
This option turns off writing of characters that are produced strictly to make the output more readable and visually appealing. Currently, those formatting characters are limited to newlines, carriage returns and spaces. This option is of benefit primarily to users who perform special automated processing on the text produced by the technology. For these users, even benign non-markup text not originally in the source document constitutes a source of extra headaches for their processing. Setting this option excludes all formatting characters from appearing in the generated markup.
It is important to note the things that setting this option does not do:
While setting this option will make it very difficult for a human to read the generated markup in a text editor, it does not affect the browser's rendering of the document.
This option does not affect the contents of the .css files since they do not contain any text from the source document.
The option does not affect spaces or newlines copied from the template as the contents of the templates are already under the control of the customer.
Data Type
xsd:boolean
Data
One of the following values:
true: Do not output formatting characters.
false: Include formatting characters in the output.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
The setting for this option determines whether or not hidden data (hidden columns, rows or sheets) in a spreadsheet will be included in the output. When set to false (the default), the hidden elements are not written. When set to true, they are placed in the output in the same manner as regular spreadsheet data.
Data Type
xsd:boolean
Data
true: Allow hidden data to be placed in the output.
false: Prevent hidden data from being placed in the output.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option will force HTML Export to place all hidden text in line with surrounding text.
Please note that enabling this option will not display hidden cells, hidden rows or hidden sheets in spreadsheet documents. Also note that when graphic documents (such as faxes) are processed by OCR software and converted to PDF, the optically recognized text may be rendered as a layer of hidden text behind the original image. In order to properly export such PDF documents, this option must be enabled.
Data Type
xsd:boolean
Data
true: Allow hidden text to be placed in the output.
false: Prevent hidden text from being placed in the output.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option is for use by people who intend to read or change the CSS style names generated by HTML Export.
By default, HTML Export creates unique style names based on the style names used in the original document. Unfortunately, there is an inherent limitation in the style names the CSS standard permits. That standard only permits the characters [a-z][A-Z][0-9] and "-". Source document style names do not necessarily have this restriction. In fact they may even contain Unicode characters at times. For this reason, the original style names may need to be modified to conform to this standard. To avoid illegal style names, HTML Export performs the following substitutions on all source style names:
If the character is a "-", then it is replaced with "--".
If the character is not one of the remaining characters ([a-z][A-Z][0-9]), then it is replaced by "-xxxx" where "xxxx" is the Unicode value of the character in hexadecimal.
Otherwise the character appears in the style name normally.
An example of one of the most common examples of this substitution is that spaces in style names are replaced with "-0020". For a more complete example of this character substitution in style names, consider the source style name My Special H1-Style!. This would be transformed to:
My-0020Special-0020H1--Style-0021
While admittedly this system lacks a certain aesthetic, it avoids the problem of how the document looks when the browser receives duplicate or invalid style names. Developers should also appreciate the simplicity of the code needed to parse or create these style names.
In addition, HTML Export will sometimes create special character attribute-only versions of styles. These have the same name as the style they are based on with "--Char" appended to the end. These styles differ from their original counterparts in that they contain no block level CSS. This more general solution replaces the solution implemented in versions 7.1 and earlier which created "--List" styles to solve a subset of this problem. This was done to work around limitations in some browsers.
Because of these CSS limitations, the simpleStyleNames (see Section B.2.3.10, "simpleStyleNames") option was created. Setting this option to true causes HTML Export to generate style names that are easy to read but are not guaranteed to be unique. It does this by discarding all characters in the original style name that are not legal in CSS style names. As one would expect, this may lead to naming collisions.
An example of a naming collision caused by setting this option can be seen if you look at source document styles named MyStyle and My $ Style. When exported with this option, both would become MyStyle. This in turn may generate confusion when viewing the document in the browser. This is because the browser will look upon the second style as being a redefinition of the first.
With the option set to false this is not a problem. The two styles would be converted to MyStyle and My-0020-0024-0020Style respectively. Because the style names are unique, the browser will not see the second style as a redefinition of the first.
As this contrived example indicates, naming collisions should be rare for most U.S. documents.
If a style name consists of nothing but illegal characters, HTML Export will create a style name for it. This style name is of the form UnnamedStyleX where "X" is a count of styles encountered so far that did not have style names for one reason or another. This behavior is expected to be very common when converting international documents in languages that are not based on 7-bit ASCII.
Data Type
xsd:boolean
Data
One of the following values:
true: Generate names that may not be unique, but are easy to read.
false: Generate unique style names that are difficult to read.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option is only valid on 32-bit Linux (Red Hat and Suse) and Solaris Sparc platforms.
When this option is set to true, the technology will attempt to use its internal graphics code to render fonts and graphics. When set to false, the technology will render images using the operating system's native graphics subsystem (X11 on UNIX/Linux platforms). Note that this option only works when at least one of the appropriate output solutions is present. For example, if the UNIX $DISPLAY variable does not point to a valid X Server, but the OSGD and/or WV_GD modules required for the Outside In output solution exist, Outside In will default to the Outside In rendering code. The option will fail if neither of these output solutions is present.
It is important for the system to be able to locate useable fonts when this option is set to true. Only TrueType fonts (*.ttf or *.ttc files) are currently supported. To ensure that the system can find them, make sure that the environment variable GDFONTPATH includes one or more paths to these files. If the variable GDFONTPATH can't be found, the current directory is used. If fonts are called for and cannot be found, HTML Export will exit with an error. Also note that when copying Windows fonts to a UNIX system, the font extension for the files (*.ttf or *.ttc) must be lowercase, or they will not be detected during the search for available fonts. Oracle does not provide fonts with any Outside In product.
If preferOITRendering is set in a particular instance of tsagent, it cannot be changed in that agent until the agent is terminated.
Data Type
xsd:boolean
Data
One of the following values:
true: Use the technology's internal graphics rendering code to produce bitmap output files whenever possible.
false: Use the operating system's native graphics subsystem.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This section discusses input handling options.
This option controls how files are handled when their specific application type cannot be determined. This normally affects all plain-text files, because plain-text files are generally identified by process of elimination, for example, when a file isn't identified as having been created by a known application, it is treated as a plain-text file.
A number of values that were formerly allowed for this option have been deprecated. Specifically, the values that selected specific plain-text character sets are no longer to be used. Instead, applications should use the defaultInputCharset option for such functionality.
Data Type
FallbackFormatEnum
Data
One of the following values:
fallbackToText: Unidentified file types will be treated as text files.
noFallbackFormat: Outside In will not attempt to process files whose type cannot be identified. This will include text files. When this option is selected, an attempt to process a file of unidentified type will cause Outside In to return an error value of SCCERR_UNSUPPORTEDFORMAT.
Default
ASCII-8
Links
C Client Implementation: OIT_FallbackFormatEnum
JAVA Client Implementation: FallbackFormatEnum
This option affects how an input file's internal format (application type) is identified when the file is first opened by the Outside In technology. When the extended test flag is in effect, and an input file is identified as being either 7-bit ASCII, EBCDIC, or Unicode, the file's contents will be interpreted as such by the export process.
The extended test is optional because it requires extra processing and cannot guarantee complete accuracy (which would require the inspection of every single byte in a file to eliminate false positives.)
Data Type
xsd:boolean
Data
One of the following values:
false: This is the default value. When this is set, standard file identification behavior occurs.
true: If set, the File Identification code will run an extended test on all files that are not identified.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option can disable the password verification of files where the contents can be processed without validation of the password. If this option is not set, the filter should prompt for a password if it handles password-protected files.
As of Release 8.3.5, only the PST Filter supports this option.
Data Type
xsd:boolean
Data
true: Ignore validation of the password
false: Prompt for the password
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
Adobe's Extensible Metadata Platform (XMP) is a labeling technology that allows you to embed data about a file, known as metadata, into the file itself. This option enables parsing of the XMP data into normal OIT document properties. Enabling this option may cause the loss of some regular data in premium graphics filters (such as Postscript), but won't affect most formats (such as PDF).
Data Type
xsd:boolean
Data
true: This setting enables parsing XMP.
false: This setting disables parsing XMP.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option controls whether or not the PDF filter will attempt to reorder bidirectional text runs so that the output is in standard logical order as used by the Unicode 2.0 and later specification. This additional processing will result in slower filter performance according to the amount of bidirectional data in the file.
Data Type
xsd:boolean
Data
true: The PDF filter uses standard ordering.
false: The PDF filter will attempt to reorder bidirectional text runs.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option allows the developer to choose how links to images in input files should be handled.The developer may request that the link be handled in one of two different ways:
Have HTML Export attempt to follow the link, convert it to the selected image type, and insert the converted object into the output (this is the default behavior).
Ignore the link altogether.
When set to true, this option will skip linked images when processing output files. If set to false, linked images will be converted and included in the output.
Data Type
xsd:boolean
Data
true: Skip linked images
false: Include linked images in the output
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option allows the user to define an offset to GMT that will be applied during date formatting, allowing date values to be displayed in a selectable time zone. This option affects the formatting of numbers that have been defined as date values (e.g., most dates in spreadsheet cells). This option will not affect dates that are stored as text.
Data Type
xsd:int
Data
Integer parameter from -96 to 96, representing 15-minute offsets from GMT. To query the operating system for the time zone set on the machine, specify the numeric value of 61440 (0xF000 in hexadecimal).
Default
0: GMT time
Links
C Client ImplementationL XSD_int
JAVA Client Implementation: Integer
This section discusses layout options.
Determines what font will be used when the font specified by the document is not available.
Currently this option is only used in certain situations where a CSS flavor of HTML is in use. Specifically, this option helps to avoid problems in some browsers where symbol fonts like Wingdings are used for the bullets in lists, and the body of the list is in a font the browser cannot find. In this case, specifying a fallback font prevents the browser from using/cascading the Wingdings font into the text of the list when the browser cannot find the font specified for the list text.
To turn off the fallback font, this option must be explicitly set to an empty string (""). While turning off the fallback font is not recommended, it will result in a minor reduction in the size of the HTML and CSS generated.
Data Type
stringData
Data
The name of the fallback font and the character set of that font.
Default
If this option is not set, "Arial" is used as the default fallback font.
Links
C Client Implementation: TS_stringData
JAVA Client Implementation: StringData
This option is used to turn off specified font-related markup in the output. Naturally, if the requested output flavor or other option settings prevent markup of the specified type from being written, this option cannot be used to turn it back on. However, specifying the size, color and font face of characters may all be suppressed by bitwise OR-ing together the appropriate combination of flags in this option.
Data Type
FontFLags
Data
The FontFlags option is a complexType data structure composed of the following Boolean variables, which may be switched on or off in any combination:
suppressSize: When switched on, turns off any character-sizing information supported in the output flavor. As an example, this flag could be useful when exporting presentation files where the author specified a very large font.
suppressColor: When switched on, suppresses specifying the color of text. This is particularly useful for exports of documents containing white text.
suppressFace: When switched on, prevents the technology from requesting a specific font (e.g. "Arial", "Courier", etc.) name for text. This can be useful if the template author feels that the original document font is not likely to be available to those who are viewing the converted document.
Default
All flags set to false, in which case no font information is suppressed.
Links
C Client Implementation: OIT_FontFlags
JAVA Client Implementation: FontFlags
Turning this option on causes the technology to generate list numbers and/or bullets as needed rather than using list markup tags. While this violates the spirit of what markup languages should do, it does cause the browsers to render the lists in a way that is more faithful to the original look of the document. An example of a list that does not view well with this option turned off is the following:
This is an example of how today's most popular browsers would render the preceding list:
This is due to the way browsers render <li> tags. The HTML standards currently do not allow any way to specify outline style list numbering.
One limitation when using this option is that standard list indentation may not be possible due to the limits of the selected output HTML flavor. At this time, only the HTML flavors where CSS is available support the kind of hanging indents normally associated with lists.
If a bullet character needs to be generated, Unicode character 0x2022 will be used. Note that many character sets do not contain this character, so the unmappable character (“*”) would be used in that case.
Data Type
xsd:boolean
Data
One of the following values:
true: Generate list item numbers and bullets.
false: Use list markup tags.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
Options related to grids have no effect on the output unless a template that has been enabled with the {## unit} template macro is in use.
This option allows the developer to specify how the "previous" and "next" relationships will work between grids. As such, it is only useful when a grid-enabled template has been selected with the template (see Section B.2.5.11, "template") option.
Setting this option to advanceAcross causes the grids.next.body template element to traverse the input spreadsheet or database by rows:
Setting this option to advanceDown causes the grids.next.body template element to traverse the input spreadsheet or database by columns:
Data Type
GridAdvanceEnu
Data
One of the following values:
advanceAcross: To traverse by rows.
advanceDown: To traverse by columns.
Default
advanceDown
Links
C Client Implementation: OIT_GridAdvanceEnum
JAVA Client Implementation: GridAdvanceEnum
Options related to grids have no effect on the output unless a template that has been enabled with the {## unit} template macro is in use.
This option allows the developer to specify the number of columns that each template "grid" (applicable only to spreadsheet or database files) should contain. As such, it is only useful when a grid-enabled template has been selected with the template (see Section B.2.5.11, "template") option.
Setting this option to zero ("0") means that no limit is placed on the number of columns in the grid. However, the settings of the pageSize, gridCols and gridRows options must all be taken into account when determining the actual dimensions of the grids used during an export. The following table describes the interaction of these options when a template is using grids:
| Grid Row/Col Value | Page Size is 0 | Page Size is not 0 |
|---|---|---|
| Grid Rows and Grid Cols are both 0. | The entire spreadsheet is exported. | The grid size is determined based on the Page Size. |
| Grid Rows is 0. Grid Cols is not 0 or the default value. | The table is broken into grids that are Grid Cols wide. Each grid contains all rows. | The number of rows in the grid are determined by the Page Size. |
| Grid Rows is not 0 or the default value. Grid Cols is 0. | The table is broken into grids that are Grid Rows wide. Each grid contains all columns. | The number of columns in the grid are determined by the Page Size. |
| Grid Rows and Grid Cols are both not set to 0 or their default values. | The table is broken into grids of the requested size. | |
| Grid Rows and Grid Cols are both set to their default values. | The table is broken into grids of the default size. | |
Also note that once the grid size has been established for a sheet in a spreadsheet or database, the sheet cannot be re-exported with different grid dimensions. The sheet may be re-exported, however, if grids are disabled using sections.current.body.
Size calculations are performed using approximations. It is expected that each cell in the grid will contain roughly 10 characters of content. Therefore, the number of cells in the grid will be roughly the page size divided by 10. Setting the pageSize option will not cause content to be truncated if it exceeds the 10 characters of content expected in a given cell. Note that the pageSize option is never used to force a grid to break into pages. Thus, once the grid dimensions have been established, no page breaking is performed on the grid.
The default value for this option was chosen to prevent problems with large spreadsheets, which can consume conversion time while creating unmanageable output. Together with the default grid rows option value, the default grid dimensions represent the largest table size HTML Export can produce that will not result in browsers locking up when they try to read the file.
The solution to this large spreadsheet problem depends on whether or not page breaking is in effect:
If page breaking is being used, use the maxreps attribute of the {## repeat} macro to prevent large files from becoming unmanageable.
If page breaking is NOT being used, spreadsheets should be exported by inserting only the first grid of the spreadsheet (grids.1.body). Don't use a {## repeat} loop to get all the grids. Test for the existence of a second grid (grids.2.body). If this grid exists, then have the template write out a message indicating that the spreadsheet's contents were truncated on export.
Implementing support for spreadsheets in this manner rather than by inserting sections.current.body improves performance only when outputting very large spreadsheets. In these special cases, only the first grid is exported, resulting in significant performance savings. This savings also has the side benefit of producing an output file that most Web browsers will have little trouble displaying.
Data Type
xsd:unsignedInt
Data
Number of columns in the grid. Use "0" (zero) to not limit the number of columns in the grid.
Default
100: This value is subject to change.
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
Options related to grids have no effect on the output unless a template that has been enabled with the {## unit} template macro is in use.
This option allows the developer to specify the number of rows that each template "grid" (applicable only to spreadsheet or database files) should contain. As such, it is only useful when a grid-enabled template has been selected with the template option.
Setting this option to zero ("0") means that no limit is placed on the number of rows in the grid. However, the settings of the pageSize, gridCols and gridRows options must all be taken into account when determining the actual dimensions of the grids used during an export.
Also note that once the grid size has been established for a sheet in a spreadsheet or database, the sheet cannot be re-exported with different grid dimensions. The sheet may be re-exported, however, if grids are disabled using sections.current.body.
Size calculations are performed using approximations. It is expected that each cell in the grid will contain roughly 10 characters of content. Therefore, the number of cells in the grid will be roughly the page size divided by 10. Setting the pageSize option will not cause content to be truncated if it exceeds the 10 characters of content expected in a given cell. Note that the pageSize option is never used to force a grid to break into pages. Thus, once the grid dimensions have been established, no page breaking is performed on the grid.
The default value for this option was chosen to prevent problems with large spreadsheets, which can consume conversion time while creating unmanageable output. Together with the default grid columns option value, the default grid dimensions represent the largest table size HTML Export can produce that will not result in browsers locking up when they try to read the file.
The solution to this large spreadsheet problem depends on whether or not page/deck breaking is in effect:
If page breaking is being used, use the maxreps attribute of the {## repeat} macro to prevent large files from becoming unmanageable.
If page breaking is NOT being used, spreadsheets should be exported by inserting only the first grid of the spreadsheet (grids.1.body). Don't use a {## repeat} loop to get all the grids. Test for the existence of a second grid (grids.2.body). If this grid exists, then have the template write out a message indicating that the spreadsheet's contents were truncated on export.
Implementing support for spreadsheets in this manner rather than by inserting sections.current.body improves performance only when inputting very large spreadsheets. In these special cases, only the first grid is exported, resulting in significant performance savings. This savings also has the side benefit of producing an output file that most Web browsers will have little trouble displaying.
Data Type
xsd:unsignedInt
Data
Number of rows in the grid. Use "0" (zero) to not limit the number of rows in the grid.
Default
5000: This value is subject to change.
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
Options related to grids have no effect on the output unless a template that has been enabled with the {## unit} template macro is in use.
In other words, this option specifies whether the "previous" and "next" relationships "wrap" at the edges of the spreadsheet or database. As such, it is only useful when a grid-enabled template has been selected with the template option.
This option is best explained by example. Consider a spreadsheet that has been broken into 9 grids by HTML Export as follows:
If this option is set to true, then the grids.next.body value after Grid 3 will be Grid 4. Likewise, the grids.previous.body value before Grid 4 will be Grid 3.
If this option is set to false, then the grids.next.body after Grid 3 will not exist as far as template navigation is concerned. Likewise, the grids.previous.body before Grid 4 will not exist as far as template navigation is concerned.
In other words, this option specifies whether the “previous” and “next” relationships “wrap” at the edges of the spreadsheet or database.
Data Type
xsd:boolean
Data
true: To continue past the edge of the spreadsheet.
false: To stop at the edge of the spreadsheet.
Default
true
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
Tab support is available by setting this option to true. When active, this option uses JavaScript to calculate tab stops and position blocks of text accordingly. Potential side effects of this include delays in loading the pages in the browser and seeing the text initially with no whitespace at all followed by a pause and then all of the tabs popping into place. In addition, this support is limited to only left tabs.
In order to take advantage of this option the following additional steps must be taken:
The template must contain a <script> tag. Something similar to the following code fragment is recommended:
{## if element=pragma.jsfile}
<script language="Javascript1.2" src="{## insert
element=pragma.jsfile}"></script>
{## /if}
The template must also run the DoTabStops routine in the <body> of the HTML. A span tag used to define the value of oneinch should follow this. Something similar to the following code snippet is recommended to accomplish this:
{## if element=pragma.jsfile}
<body onload="DoTabStops()">
<span id="oneinch" style="width: 1in"></span>
{## else}
<body>
{## /if}
A flavor of HTML that supports CSS must be used.
The user's browser must support JavaScript and this support must be enabled.
Data Type
xsd:boolean
Data
One of the following values:
true: Use JavaScript to create tabs.
false: No tab support.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option sets a suggested page size for the output generated. This means that the text of the document is broken up into "pages" of approximately the requested size. Each page is stored as a separate output file.
This feature is particularly useful when converting documents that are poorly structured. Many documents lack the kind of style information HTML Export normally uses to break the document into pieces based on things like headings. By setting this option, the exported document can be presented as a set of more manageable pieces rather than a single giant output file. It is also useful with documents that are structured but have large pieces in the structure.
If page breaking is activated (set to a non-zero value), HTML Export will buffer the entire output document in memory during conversion. Conversion times and memory requirements will increase accordingly in this case.
The size specified by this option is given in characters of text. Only text inserted from the input document is counted in the page size. Thus, "as is" text from the template is not counted against the page size. Also, markup tags are not counted in the page size. In addition, some template inserts are normally used as attributes to markup tags, and as such they are not counted in page size calculations no matter how they are actually used. Those template inserts are:
pragma.charset
pragma.jsfile
pragma.cssfilename
sections.x.itemnum
sections.x.reflink
A page size of zero ("0") indicates that this option is turned off and no page breaking is done.
When this option is turned on, the page breaking rules are as follows:
Hard page breaks in the document always trigger a page break. Soft page breaks are ignored.
A page break may be specified in the template with the {## unit break} macro.
A page boundary will never be created in the middle of a paragraph. As many paragraphs as possible will be written without exceeding the requested page size. Page sizes are not hard limits on content however. One situation where the page size could be exceeded would be if a single paragraph exceeds the page size.
When grid-enabled templates are in use, the exported grids are not broken based on the setting of this option. However, this option may affect the size of grids generated.
Use of this option will not cause the contents of cells within a grid to be truncated.
When grids are not in effect, spreadsheets and databases will be broken based on page size. For these section types, checks for page breaks will be made after each full row from the spreadsheet or database is written.
It is up to the template author to then connect these pieces with the appropriate links. In order to use this option, the template must be equipped to use the {## unit} syntax.
Note that templates enabled with the {## unit} syntax may be mixed with templates that do not contain {## unit} macros. In this case, page breaking will only occur in the template that is enabled with {## unit} macros. An example of where this would be desirable is a "table of contents" template that uses two sub templates to each fill in the contents of a frame. The frame containing the actual table of contents could avoid being broken into pages by not containing any {## unit} macros. The frame containing the actual document contents could then support paging by using {## unit} macros.
Data Type
xsd:unsignedInt
Data
Approximate page size in characters.
Default
0: No page size limit.
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
Most browsers support flowing text around images. Unfortunately, even the most popular browsers also have bugs in their support for this feature that occasionally result in document elements overlapping. This option allows users of HTML Export to choose if they would rather have text flowing around graphics or if they are willing to sacrifice that feature in order to prevent browser overlap bugs.
When this option is turned on (set to true), HTML Export prevents browsers from causing graphic overlap problems by surrounding all <img> tags with <div> tags. The overlap problems occur most frequently when the browser is displaying a document that has a mix of left- and right-aligned graphics in close proximity to each other. Resizing the browser window horizontally will sometimes expose this problem if it does not appear initially.
Because these browser bugs are infrequently seen, this option is turned off (set to false) by default. However, setting this option to false does not guarantee that text will be able to flow around graphics in the browser the same way it does in the original document. There are two problems which can prevent this from occurring.
The first problem is that when objects are placed using positional frames. Unfortunately, most new word processing formats do this automatically. When positional frames are used, each object exists in its own frame. HTML Export converts each frame as a single paragraph. Therefore, the objects are written one after the other even if they were originally placed side by side in the source document.
The second problem is associated with image alignment. For some images, HTML Export is unable to obtain the alignment of the image, so the alignment of the paragraph it is contained in is used instead. The reason HTML Export uses this alignment, which is not necessarily 100% correct, is because without adding "align=" in the <img> tag, text does not wrap around images in browsers.
Also note that setting this option to false will have no effect if the strictDTD flag of the compliance option is set. This is because <div> tags are not allowed inside <p> tags, so HTML Export cannot use <div> tags to prevent graphics from overlapping.
Data Type
xsd:boolean
Data
true: Allow text flow around graphics.
false: Prevent browser image overlap problems.
Default
false
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option allows the developer to specify the template file that the technology uses to generate its output.
Data Type
IOSpec
Data
A file location specification. The following are the currently valid IOSpec values:
path: A file-system path to a file.
url: A URL to a file.
redirect: A spec that can be opened by an open function that is supplied by the caller. This type is only supported when the calling application is using the C/C++ or Java client API.
Default
If no template is specified, a standard template is used.
Links
C Client Implementation: TS_IOSpec
JAVA Client Implementation: IOSpec
This section discusses compression options.
This option can disable access to any files using JPEG compression, such as JPG graphic files or TIFF files using JPEG compression, or files with embedded JPEG graphics. Attempts to read or write such files when this option is enabled will fail and return the error SCCERR_UNSUPPORTEDCOMPRESSION if the entire file is JPEG compressed, and grey boxes for embedded JPEG-compressed graphics.
The following is a list of file types affected when this option is disabled:
JPG files
Postscript files containing JPG images
PDFs containing JPEG images
Note that the setting for this option overrides the requested output graphic format when there is a conflict. In the case of HTML Export, the output graphic type is set to noGraphics in these situations.
Data Type
xsd:boolean
Data
true: Allow access to files that use JPEG compression
false: Do not allow access to files that use JPEG compression
Default
true
This option can disable access to any files using Lempel-Ziv-Welch (LZW) compression, such as .GIF files, .ZIP files or self-extracting archive (.EXE) files containing "shrunk" files. Attempts to read or write such files when this option is enabled will fail and return the error SCCERR_UNSUPPORTEDCOMPRESSION if the entire file is LZW compressed, and grey boxes for embedded LZW-compressed graphics.
The following is a list of file types affected when this option is disabled:
GIF files
TIF files using LZW compression
PDF files that use internal LZW compression
TAZ and TAR archives containing files that are identified as FI_UNIXCOMP
ZIP and self-extracting archive (.EXE) files containing "shrunk" files
Postscript files using LZW compression
Although this option can disable access to files in ZIP or EXE archives stored using LZW compression, any files in such archives that were stored using any other form of compression will still be accessible.
The setting for this option overrides the requested output graphic format when there is a conflict. In the case of HTML Export, the output graphic type is set to noGraphics in these situations.
Data Type
xsd:boolean
Data
true: LZW compressed files will be read and written normally.
false: LZW compressed files will not be read or written.
Default
true
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This section discusses graphics options.
This option allows the developer to specify interlaced or non-interlaced GIF output. Interlaced GIFs are useful when graphics are to be downloaded over slow Internet connections. They allow the browser to begin to render a low-resolution view of the graphic quickly and then increase the quality of the image as it is received. There is no real penalty for using interlaced graphics.
This option is only valid if the graphicType option is set to FI_GIF.
Data Type
xsd:boolean
Data
One of the following values:
true: Produce interlaced GIFs.
false: Produce non-interlaced GIFs.
Default
true
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This is an advanced option that casual users of this technology may safely ignore. It allows a hard limit to be set for how tall in pixels an exported graphic may be. Any images taller than this limit will be resized to match the limit. It should be noted that regardless of whether the graphicWidthLimit option is set or not, any resized images will preserve their original aspect ratio.
Note that this option differs from the behavior of setting the height of graphics by using HEIGHT= in a {## insert} statement in the template in two ways:
This option sets an upper limit on the image height. Images larger than this limit will be reduced to the limit value. However, images smaller than this height will not be enlarged when using this option. Setting the height using the height attribute in the template causes all non-embedded images to be reduced or enlarged to be of the specified height.
This option works for embedded images as well as non-embedded images. Setting a height using HEIGHT= in a {## insert} statement in the template causes only non-embedded images to be of the specified height.
Data Type
xsd:unsignedInt
Data
The maximum height of the output graphic in pixels. A value of zero causes this option to be ignored.
Default
0: No absolute height limit specified.
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
This is an advanced option that casual users of this technology may safely ignore.
While this option is used to help compute table sizes, it is primarily a graphics option. Early browsers and versions of the HTML standard limit the specification of image sizes to dimensions in pixels. For images in particular, this is somewhat natural as GIF, JPEG, and PNG are bitmap formats whose sizes are defined in pixels. However, many of the source graphics and tables converted by HTML Export specify their size in physical units such as inches or centimeters, and there is no way for HTML Export to know how big a pixel is on the target device for the converted document. In fact, a single document may ultimately be viewed on many devices, each with a different number of pixels or dots per inch (DPI). Knowing this information can be important. If graphics are converted to be too small, image detail will be lost. Conversely, if the graphics are converted to be too large, files will take longer to download than is desired.
This option allows the user to specify the output graphics device's resolution in DPI and only applies to images whose size is specified in physical units (in/cm). For example, consider a 1" square, 100 DPI graphic that is to be rendered on a 50 DPI device (graphicOutputDPI is set to 50). In this case, the size of the resulting WBMP, TIFF, BMP, JPEG, GIF, or PNG will be 50 x 50 pixels.
You may also specify the value 0 for the DPI, which will cause the output image to be created with identical pixel dimensions as the original input image, without consideration for physical measurements of image size.
Setting this option to 0 may result in the creation of extremely large images. Be aware that there may be limitations in the system running this technology that could result in undesirably large bandwidth consumption or an error message. Additionally, an out of memory error message will be generated if system memory is insufficient to handle a particularly large image.
Also note that the 0 setting will force the technology to use the DPI settings already present in raster images, but will use the current screen resolution as the DPI setting for any other type of input file.
For some output graphic types, there may be a discrepancy between the value set by this option and the DPI value reported by some graphics applications. The discrepancy occurs when the output format uses metric units (DPM, or dots per meter) instead of English units (DPI, or dots per inch). Depending on how the graphics application performs rounding on meters to inches conversions, the DPI value reported may be 1 unit more than expected. An example of a format which may exhibit this problem is PNG.
Data Type
xsd:unsignedInt
Data
The DPI to use when exporting graphic images. The maximum value allowed is 2400 DPI.
Default
96: 96 dots per inch.
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
This is an advanced option that casual users of HTML Export may safely ignore.
This option is used to set the maximum size of the exported graphic in pixels. It may be used to prevent inordinately large graphics from being converted to equally cumbersome output files, thus preventing bandwidth waste.
graphicSizeLimit takes precedence over all other options and settings that affect the size of a converted graphic. For example, if the template specifies image dimensions that exceed this size, those dimensions will be used only to calculate the aspect ratio of the final image. The image's dimensions will be restricted to produce a graphic no larger than this limit allows.
Data Type
xsd:unsignedInt
Data
The total number of pixels in the output graphic. A value of zero ("0") causes this option to be ignored.
Default
0: Option is turned off.
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
This option determines the method used to size graphics. The developer can choose among three methods, each of which involves some degree of trade off between the quality of the resulting image and speed of conversion.
Using the quick sizing option results in the fastest conversion of color graphics, though the quality of the converted graphic will be somewhat degraded. The smooth sizing option results in a more accurate representation of the original graphic, as it uses anti-aliasing. Antialiased images may appear smoother and can be easier to read, but rendering when this option is set will require additional processing time. The grayscale only option also uses antialiasing, but only for grayscale graphics, and the quick sizing option for any color graphics.
The smooth sizing option does not work on images which have a width or height of more than 4096 pixels.
Data Type
GraphicSizeMethodEnum
Data
One of the following values:
quick: Resize without antialiasing
smooth: Resize using antialiasing
smoothGray: Resize using antialiasing for grayscale graphics only (no antialiasing for color graphics)
Default
smooth
Links
C Client Implementation: OIT_GraphicSizeMethodEnum
JAVA Client Implementation: GraphicSizeMethodEnum
This option allows the user to set the color used as the "transparency color" in the output graphic file. Naturally, this option is only used when the selected output graphic file format supports transparency (GIF and PNG only). If the option is not set, the default behavior is to use the same color value that the input file used as the transparency color.
Use the SCCVWRGB(r, g, b) macro to create the color value to pass to this option. The red, green and blue values are percentages of the color from 0-255 (with 255 being 100%). Note that this macro should be used to set a variable of type xsd:unsignedInt and that variable should then be passed to the set option routine (instead of trying to use the macro as part of the set option call directly).
Since there is no way to "unset" an option once it has been set, the developer may set the option to -1 if they wish to revert to the default behavior.
Data Type
xsd:unsignedInt
Data
An RGB color value created with the SCCVWRGB(r, g, b) macro.
Default
-1: Use the same transparency color as the source document.
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
This option allows the developer to specify the format of the graphics produced by the technology.
When setting this option, remember that the JPEG file format does not support transparency.
Though the GIF file format supports transparency, it is limited to using only one of its 256 available colors to represent a transparent pixel ("index transparency").
PNG supports many types of transparency. The PNG files written by HTML Export are created so that various levels of transparency are possible for each pixel. This is achieved through the implementation of an 8-bit "alpha channel".
There is a special optimization that HTML Export can make when this option is set to noGraphics. Some of the Outside In Viewer Technology's import filters can be optimized to ignore certain types of graphics.
It should be noted that unpredictable and potentially undesirable output will occur if this option is set to noGraphics when a transformation is initiated and the template then attempts to use the {## option} macro to turn graphics back on.
The settings for options in Compression may force an override of the value for this option.
Data Type
GraphicTypeEnum
Data
One of the following values:
gif: GIF graphics
jpeg: JPEG graphics
png: PNG graphics
noGraphics: Graphic conversion will be turned off
Default
jpeg
Links
C Client Implementation: OIT_GraphicTypeEnum
JAVA Client Implementation: GraphicTypeEnum
This is an advanced option that casual users of this technology may safely ignore. It allows a hard limit to be set for how wide in pixels an exported graphic may be. Any images wider than this limit will be resized to match the limit. It should be noted that regardless of whether the graphicHeightLimit option is set or not, any resized images will preserve their original aspect ratio.
Note that this option differs from the behavior of setting the width of graphics by using WIDTH= in a {## insert} statement in the template in two ways:
This option sets an upper limit on the image width. Images larger than this limit will be reduced to the limit value. However, images smaller than this width will not be enlarged when using this option. Setting the width using the width attribute in the template causes all non-embedded images to be reduced or enlarged to be of the specified width.
This option works for embedded images as well as non-embedded images. Setting a width using WIDTH= in a {## insert} statement in the template causes only non-embedded images to be of the specified width.
Data Type
xsd:unsignedInt
Data
The maximum width of the output graphic in pixels. A value of zero causes this option to be ignored.
Default
0: No absolute width limit specified.
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
This option allows the developer to specify the lossyness of JPEG compression. The option is only valid if the graphicType option is set to jpeg.
Data Type
xsd:unsignedInt
Data
A value from 1 to 100, with 100 being the highest quality but the least compression, and 1 being the lowest quality but the most compression.
Default
100
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
This section discusses spreadsheet and database options.
This option has been deprecated beginning with the 8.2 version of the product. Please use the showSpreadsheetHeadings and spreadsheetBorders options instead.
This option affects database files the same way it affects spreadsheets.
This option allows users to speed up the conversion of large, sparse spreadsheets by turning off the table borders HTML Export generates by default (true is the default setting for this option). Setting this option to false turns off table border generations, reducing the amount of HTML written and enabling rowspan and colspan table tag attributes so that empty cells can be skipped. For large, mostly empty spreadsheets, this can result in greatly reduced conversion time and output file size(s). The output appears in a format similar to that used by the original application when printing the file.
The default is to show borders (option set to true). This prevents problems with most browsers, which tend to render the text in a way that makes adjacent cells hard to distinguish. This output appears in a browser in a format similar to that used by the original application when displaying the file on-screen.
This option must be set to the default value when the output format does not support tables.
When the option is set to false, the following caveats apply:
If the spreadsheet being processed stores data by row (such as Microsoft Excel spreadsheets) rather than by column (such as Quattro files), additional optimizations are possible. The technology will use colspan to shrink the output when two or more adjacent cells in a row are empty. When two or more adjacent rows are completely empty, they are ignored and not included in the output.
Note that if there are merged cells in the input document, the technology will not produce perfectly optimized output. Instead, rowspan and colspan will not be used to compress empty cells until after the merged cells are processed.
This option disables the creation of Row and Column headings ("1", "2", "3" / "A", "B", "C").
Data Type
xsd:boolean
Default
true
Links
C Client Implementation: XSD_boolean
JAVA Client Implementation: Boolean
This option supersedes some of the functionality from the now discontinued showSpreadsheetBorder option.
This option determines how borders will be handled for spreadsheet and database files.
There are three valid values for this option:
createBorderIfMissing: If a CSS output flavor is in use, this forces borders to be created if none are present in the (entire) table. By default, most apps do not include borders when creating these types of files. When needed, HTML Export will generate thin borders between cells. Otherwise, the borders specified in the table are used.
Using borders makes it easier to read the output data by preventing values from running together when there is not much space between cells. This output appears in a browser in a format similar to that used by the original application when displaying the file on-screen.
The behavior of this setting matches the old default border behavior of the discontinued showSpreadsheetBorder option.
If a CSS output flavor is not in use, then borders are put around all cells no matter how the input document is formatted. This is because individual cell border information may not be specified in HTML without CSS.
This is the default behavior for this option.
bordersOff: This setting forces the borders always to be off, regardless of borders specified in the source document. This option setting does not distinguish between CSS and non-CSS output flavors being used. Turning borders off has the following advantages:
It allows HTML Export to use optimizations that speed up the conversion of large, sparse files. It does this by enabling rowspan and colspan table tag attributes to be used to span empty cells. It also reduces the amount of HTML needed to be written for individual cells. For large, mostly empty spreadsheets, this can result in greatly reduced conversion time and output file size(s). The output appears in a format similar to that used by the original application when printing the file.
For left aligned text and data cells, a special optimization has been made to merge those cells with any empty cells on the right.
The following caveats apply to the optimization:
If the spreadsheet being processed stores data by row (such as Microsoft Excel spreadsheets with portrait page orientation) rather than by column (such as Quattro files), additional optimizations are possible. The technology will use colspan to shrink the output when two or more adjacent cells in a row are empty. When two or more adjacent rows are completely empty, the rows are skipped, and the row height of the next non-empty row is increased.
Note that if there are merged cells in the input document, the technology will not produce perfectly optimized output. Instead, colspan will not be used to compress empty cells until after the merged cells are processed.
The behavior of this option setting matches the old border behavior of the now discontinued showSpreadsheetBorder option when it was set to FALSE. However, this option does not disable the creation of Row and Column headings ("1", "2", "3" / "A", "B", "C"). To do that, use the new showSpreadsheetHeadings option.
If the current row has frames in it, we will not span those cells.
useSourceBorders: If a CSS output flavor is being used, then this value sets the borders according to what is specified in the source document.
If a CSS output flavor is not in use, then borders are put around all cells no matter how the input document is formatted. This is because individual cell border information may not be specified in HTML without CSS.
Data Type
SpreadSheetBordersEnum
Data
createBorderIfMissing: Use source document borders. If no borders are in the table, automatically create borders.
bordersOff: Do not write any table borders.
useSourceBorders: Use source document borders.
Default
createBorderIfMissing
When this option is set to true, row and column headings ("1", "2", "3" / "A", "B", "C") are included in the output for spreadsheet and database files. When set to false, no row and column headings are created. The default for this option is true.
This option supersedes some of the functionality from the now discontinued showSpreadsheetBorder option.
Data Type
xsd:boolean
Data
true: Show row and column headings.
false: Do not show row or column headings.
Default
true
This section discusses page rendering options.
This option controls display of email headers in the output.
Data Type
EmailHeaderOutputEnum
Data
One of these values:
emailHeaderStandard: Displays "To," "From," "Subject," "CC," "BCC," "Date Sent," and "Attachments" header fields only. The filter outputs any fields not listed above as hidden fields, so they will not display.
emailHeaderAll: Displays all available email headers.
Default
emailHeaderStandard
Links
C Client Implementation: OIT_EmailHeaderOutputEnum
JAVA Client Implementation: EmailHeaderOutputEnum
This section discusses font rendering options.
This is an advanced option that casual users of HTMLExport may ignore.
This option sets the font to use when the chunker-specified font is not available on the system. It is also the font used when the font in an source file embedding is not available on the system performing the conversion.
This option only affects the conversion of vector graphic images. It does not affect in any way the <font> tags used for text markup in the output.
Data Type
The DefaultFont option is a complexType data structure composed of two elements. The elements are as follows:
Parameters
fontName: An xsd:string value indicating tThe name of the font. For example, "Helvetica Compressed." The default is "Arial", however this default is constrained by the fonts available on the system.
height: An xsd:unsignedShort value indicating the size of the font in half points. For example, a value of 24 will produce a 12-point font. This size is only applied when the font size is not known. The default is 10-point, however this default is constrained by the font sizes available on the system. Please note that this only affects the size of fonts in embedded vector images in the rare case where a default font size is not specified in the embedding.
Links
C Client Implementation: OIT_DefaultFont
JAVA Client Implementation: DefaultFont
This is an advanced option that casual users of HTML Export may ignore.
This option sets or gets printer font aliases. For example, Chicago=Arial forces Chicago to be output as Arial.
This option only affects the conversion of vector graphic images when the font specified in the original document is not available on the system doing the conversion. It does not affect in any way the <font> tags used for text markup in the output.
Data Type
xsd:string
Data
The xsd:string value takes the form of font=alias, as in this example:
Chicago=Arial
The technology assumes the following default mappings. The first value is the font name, the second is the alias name.
Chicago = Arial
Geneva = Arial
New York = Times New Roman
Helvetica = Arial
Helv = Arial
times = Times New Roman
Times = Times New Roman
Tms Roman = Times New Roman
Symbol = Symbol
itc zapfdingbats = Zapfdingbats
itc zapf dingbats = Zapfdingbats
Links
C Client Implementation: XSD_string
JAVA Client Implementation: String
This section discusses file system options.
This option supplies information to OIT when information is required to open an input file. This information may be the password of the file or a support file location.
Further information about how Transformation Server implements this option will be forthcoming.
Used to define the number of bytes that that will read from disk into memory at any given time. Once the buffer has data, further file reads will proceed within the buffer until the end of the buffer is reached, at which point the buffer will again be filled from the disk. This can lead to performance improvements in many file formats, regardless of the size of the document.
Data Type
xsd:unsignedInt
Data
The size of the buffer in kilobytes.
Default
2
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
Used to define a maximum size that a document can be and use a memory-mapped I/O model. In this situation, the entire file is read from disk into memory and all further I/O is performed on the data in memory. This can lead to significantly improved performance, but note that either the entire file can be read into memory, or it cannot. If both of these buffers are set, then if the file is smaller that the dwMMapBufferSize, the entire file will be read into memory, if not, it will be read in blocks defined by the dwReadBufferSize.
Data Type
xsd:unsignedInt
Data
The size of the buffer in kilobytes.
Default
8192
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
The maximum size that a temporary file can occupy in memory before being written to disk as a physical file. Storing temporary files in memory can boost performance on archives, files that have embedded objects or attachments. If set to 0, all temporary files will be written to disk.
Data Type
xsd:unsignedInt
Data
The size of the buffer in kilobytes.
Default
2048
Links
C Client Implementation: XSD_unsignedInt
JAVA Client Implementation: UnsignedInt
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|