This section discusses the component architecture of a generic tool that uses Litgen.dll as one of the components.
Because Litgen.dll is a component of a larger workflow, diagramming its place in the conversion tools continuum helps define its role. The following diagram shows how Litgen.dll can integrate within a fictitious tool, the Acme Conversion Tool.
Note: This diagram assumes an HTML conversion. Other source formats will require different steps.
Any error return from any method is fatal. Litgen.dll does not track error codes internally, so if a caller doesn’t notice a failure from one method, there may be no other indication that the output file is corrupt.
Note: Call ILITWriter::Fail()after any failure.
All methods are clamped to their documented return codes. These return codes are not the primary mechanism for providing information about a failure. The Litgen.dll client should implement ILITCallback and supply it to Litgen.dll (via ILITWriter::SetCallback()) to provide information about a failure. Various messages are sent through ILITCallback during content preparation. These messages supply much more detail about the problem and how to correct it.
Litgen.dll has no contact with input files, therefore source file structure is not important for successful conversion tools. Tag(…, TRUE) and EndChildren() calls must be balanced. Litgen.dll requires input that appears as if it was parsed from clean HTML files and an OEB package file. The files need not actually exist.
Although the current implementation allows you to encode almost anything as content, as long as it’s well-formed, it is considerably less space-efficient to encode custom tagsets.
© 2000 Microsoft Corporation. All rights reserved. Terms of use.