The settings of the options and the currently open webs are kept in the file PANORAMA.INI, located in the main Windows directory.

The Setup file configures the handling of notations. It also allows you to specify a font substitution table to map fonts unknown to your system onto similar fonts. This is necessary to make the style sheets portable.

The font substitutions are defined in the SETUP file using the keyword FONTMAP. For instance, if you are accessing a Unix style sheet on a PC, you might want Times mapped to Times New Roman and Helvetica mapped to Arial. To achieve this, add the following lines: FONTMAP "Times" "Times new Roman" FONTMAP "Helvetica" "Arial" The font name "*" is used to set up a default font. If you specify FONTMAP "*" "Times New Roman" then the font Times New Roman will be the default font when no font is specified in the style sheet.

The SDATA.MAP file, also located in the &p; installation directory, is used to map foreign, system dependent SDATA characters. Consult this file regarding the format of declarations.

Because they are based on a standard, SGML software applications can share common sets of files. To harmonize the use of shared files, the SGML Open consortium has adopted a technical resolution that specifies how applications can retrieve such files by using a common catalog file; &p; supports the SGML Open entity catalog scheme. The catalog maps symbolic names (so-called public identifiers) to corresponding physical files. A summary of this scheme may be found on the SGML Open WWW server, at the URL &enturl;.

The CATALOG file, stored in the CATALOG directory within the &p; directory, resolves the mapping between public identifiers and the corresponding actual file. All file paths are relative to the CATALOG file itself, but can of course be specified in full.

The default catalog resides in the &p; directory; if you are using another SGML application that also supports the SGML Open catalog, you can specify the path to that catalog file in various ways.

To specify an alternative catalog file, change the CATALOG value in your WIN.INI file, so that its value corresponds to the path of your main catalog file.

Though the SGML Open entity catalog scheme permits user-defined extensions, Synex Information has in the interest of portability preferred not to deviate from the plain catalog format. Therefore, application dependent files—such as style sheets and navigators—are designated in a directory called ENTITYRC also located in the &p; directory. The corresponding file is named ENTITYRC as well.

When &p; opens a file, it also searches the same directory for files by the name of CATALOG and ENTITYRC. In this manner, you can specify catalogs at run-time, whose contents will have precedence over the &p; directory catalogs.

Verbatim formatting means that element contents appear formatted with line breaks preserved from the SGML source. This can be achieved by inserting a suitable declaration in the ENTITYRC file or by inserting a processing instruction in the local declaration subset.

This is not a style sheet option as the binding has to be done early, prior to the parsing of the document content. There are two ways of specifying verbatim processing:

You can specify VERBATIM "gi1 gi2 gi3..." in the ENTITYRC file at the corresponding DTD entry, where the GIs are the identifiers for the corresponding element.

Alternatively, you can specify a processing instruction of the form:

immediately after the inclusion of the DTD in the document.

Verbatim formatting has already been covered as one of the specifications you can make in the ENTITYRC file, or as a processing instruction.

The DOCTITLE declaration is used to point out the element containing the document title, to be displayed in the browser window caption.

There are two ways of specifying the document title:

You can specify DOCTITLE "GI" in the ENTITYRC file at the corresponding DTD entry, where the GI is the identifier for the corresponding element, optionally qualified by immediate ancestors, separated with commas.

Alternatively, you can specify a processing instruction of the form: prior to the document instance.

If &p; is unable to find any stylesheet in the ENTITYRC file or a corresponding STYLESPEC processing instruction, it will search for a file called DTDNAME.SSH to use as a default navigator, where DTDNAME is the filename of the DTD (less the file suffix).

If &p; is unable to find any navigator in the ENTITYRC file or a corresponding NAVIGATOR processing instruction, it will search for a file called DTDNAME.NAV to use as a default navigator, where DTDNAME is the filename of the DTD (less the file suffix).

Public identifiers are often used to increase the portability of SGML documents. The public identifier is a symbolic name for an entity which is eventually resolved to a system identifier.

&p; uses public identifiers in the CATALOG and ENTITYRC files, and in style sheet and navigator definitions as well.

If two public identifiers are identical, they are interpreted as representing the same information. In the interest of processing speed, and to reduce network congestion, &p; will use a copy of the entity on the local file system instead of fetching it from some World Wide Web server as long as both public identifiers are identical.

The public identifier for the DTD of this document is -//Synex Information AB//DTD Panorama Manual 1.2//EN. A so-called formal public identifier (or FPI for short) has a well-defined structure as illustrated by the table below:

Public identifiers are resolved by the Entity Manager into system identifiers (that are, naturally, system dependent). &p; supports three kinds of system identifiers: Relative identifiers.

As an example, you may want to review the public and system identifier pairs in the CATALOG and ENTITYRC files.

While the DTD describes the logical structure of a document, there are general concepts that transcend applications of SGML, of which hyperlinking is a prime example. Rather than define tag sets for hypertext, the HyTime standard defines a meta-DTD, where many useful constructs are defined much like in an ordinary DTD. However, to create a correspondence between the HyTime concept and the tag actually being used, HyTime requires elements to have an attribute called HyTime. By virtue of the HyTime attribute, an application may use any tag naming scheme, as the corresponding HyTime concept can be readily identified. This mechanism is called an architectural form.

Names below that are prefixed with a percent sign are SGML parameter entities to stress the fact that these tags can have any name by virtue of the HyTime architectural form.

&p; requires at least the following element declarations:

The ellipsis (...) indicates omitted declarations.

&p; requires that the nmlist entities be declared in the local document. We do not yet support the case where the nametype is declared as an entity and docorsub has a declared entity value, meaning that the entities in the nmlist element are declared in the entity referenced by the docorsub entity.