sdc comes with a couple of document type definitions (DTD's).
The DTD's feature the reuse of text, minimization of markup and readability of the SGML source. They share their elements as much as possible.
The formatting differs due to the features possible in the target format and to the rules common for the type of the document. This includes the automated rearrangment of text and insertion of standard parts like contents sections, sorted index and bibliography. The latter for instance is composed from the items of a database which are referenced in the document. For some formats the output may be spread over a couple of files. See the target type documentation for details.
According to the goal of text reuse and the aim to support many target formats, these DTD's don't attempt to cover each and every case possible. Instead, they try to provide all elements nessesary for daily use and leave the implementation of special features to extensions.
It is also possible to have parts of the documents using other notations. E.g., pictures drawn with tgif, xfig, the @Fig package of Lout or encapsulated postscript.
It is fairly easy to coerce sdc to parse documents with other DTD's. But this implies to write rules for formatting in the desired target format(s), or fit in another parsing stage which changes it into a form as if it was marked acording to a supported DTD.
The transformation (formating) is described by files of scheme code
related to both, the document type and the target format. Only
combinations of common value are supported by default. (For instance
for letters only PostSript output is defined.)
1.3 OPTIONS
Some target formats (e. g., HTML) hard wire the given name of the output file into the file(s) created (for cross referencing). Though it's wise not to give a path including a directory but only a file name for the output file.
If the -O switch is omitted a guess is made from the extension of the output file name. If neither gives a target type this is an error.
<!ENTITY % entityname "INCLUDE" >
precedes the processing of the documents. This is useful for optional including of marked sections. Refer to the manual sgmls(1) for a detailed description. This option is passed to sgmls.
Startup files can have their own arguments. If the argument given with a -R option contains a colon, only the half up to that colon gives the file name to be loaded. The rest of the argument (without the colon) is assigned to the variable *-R-option-argument* while the specified file is loaded. If there was no colon in the argument, #f is assigned.
With the -R option there are additional (long) options available to change the over all behavior. These are used by supplying one or more of the following file names to the -R option.
Attention! Be careful to supply the exact name to the
-R option. The same policy as for dot files applies to those
files: if they don't exist they are silently not loaded! There is no
warning message.
1.4 RETURN CODE
sdc returns an exist value of 0 upon successful SGML parsing and 1
if the input does not conform to the DTD. Semantic errors like
unresolved references are currently not covered.
1.5 EXAMPLES
Set the environment variable DOCPATH to a useful value like:
setenv DOCPATH $HOME/text/
Call sdc to generate a html page from text.sgml:
sdc -o text.html text.sgml
Usually a good value for DOCPATH is something like $HOME or $HOME/text:$HOME/doc.
Usually it's good to leave this variable alone.
Usually it's good to leave this variable alone, except if you want to overwrite some but not all files of the library.
sdc uses the files and directory structure in its library to parse the document and determine the formatting. For a descrition of this refer to the developers documentation.
Furthermore sdc uses the
current working directory
when writing temporary files.
(See the developers documentation for reasoning.)
Make sure to change into a writable directory before invoking sdc.
1.8 CONFORMING TO
The underlying sgmls conforms to ISO 8879. Therefore sdc too.
1.9 NOTES
At the moment there is no complete developers documentation
available. Support for RTF output is still far from complete and uses
the old mechanism.
1.10 DIAGNOSTICS
An error
SGML error at file, line number
comes from the underlying SGML parser and indicates text not conforming to the document type definition. Usually this will imply a lot of other errors.
*** ERROR:bigloo:eval:
Indicates a bug in the format translation files.
1.11 AUTHOR
This was written by Jörg Wittenberger.
1.12 SEE ALSO
sgmls(1) , lout(1) , info(5) , latex(1) , xfig(1) .