Font Style Subsystem
From Open Watcom
Contents |
Scope and Status
This page discusses the Font Style subsystem, that is, it will eventually gather together in one place all available information on Font Styles as used in wgml.
At the moment, this is a preliminary effort, based mainly on investigation of the :DEFAULTFONT and :FONTSTYLE blocks. It exists because that investigation produced results which transcended the intended scope of the discussion of those blocks in the context of binary driver files.
Participating Actors
The command-line option FONT allows a Font Style to be specified.
These document tags are documented in WGML Reference under :DEFAULTFONT as involved in this subsystem:
- The highlight phrases tag :HP0.
- The highlight phrases tag :HP1.
- The highlight phrases tag :HP2.
- The highlight phrases tag :HP3.
Note that other document tags may be involved, and that, at this point, no verification has been done.
These binary file definition blocks are involved:
- The :DEFAULTFONT block: attribute fontstyle.
- The :FONTSTYLE block: attribute type and the various sub-blocks, which wgml uses to actually produce the desired Font Style in the output document.
Patterns of Interaction
In WGML Reference, it is clearly stated that the :HP0 through :HP3 tags use the :DEFAULTFONT blocks with values of the attribute font of "0" through "3" (respectively). This also relates the :HP0 through :HP3 tags to the values of the attributes fontstyle within those :DEFAULTFONT blocks.
There is no documentation for the :FONTSTYLE block. However, it seems likely that the value of the attribute fontstyle of the :DEFAULTFONT block is used to identify, by matching the attribute type of the :FONTSTYLE block, which :FONTSTYLE block is to be used by wgml to implement the specified Font Style on the given device. This has yet to be tested, however.
When testing the treatment of an empty string as the value of the attribute font in the :UNDERSCORE block, it was discovered that, if the value of attribute fontstyle in a :DEVICEFONT block did not match a value in a :FONTSTYLE block, then wgml 4.0 would stop processing the document.
Font Style Names
The WGML Reference contains this statement about the attribute fontstyle:
The font style values may be applied to any font. The value of the fontstyle attribute value is a keyword value which defines the style of the font. The keyword value may be one of PLAIN, UNDERSCORE, BOLD, USBOLD, UNDERLINE, or ULBOLD.
which clearly states that these are "keyword values", which, to my mind, implies that only the indicated values may be used.
Examination of actual source files showed ULINE in use and preliminary testing showed that USCORE works as well; as a result, these values were originally interpreted as alternative forms of UNDERLINE and UNDERSCORE (although, since the WGML Reference is older than the version 3.33/4.1 gendev and wgml the source files were created for, it is possible that the shorter forms replaced the longer forms at some point). Further testing, however, shows that any string value may be used, subject to the conditions shown below.
Since the Font Style name must match wherever it is used, it seems reasonable to conclude that these conditions apply to the Font Style name in all contexts, although not all contexts have been tested yet:
- It cannot contain embedded spaces.
- It cannot contain more than 79 characters.
Testing shows that the Font Style name is converted to all-lower-case, at least in :FONTSTYLE blocks.
Functional Issues
The entire point of using device, driver and font definitions is to allow any document to be output to any device. This is done with wgml by having two classes of directories: those used to house documents, and those used to house the device, driver and font defintions and the libraries created from them by gendev.
If, for each device/driver definition, a unique set of Font Styles is defined, then this purpose is defeated: documents will either have to be written for one specific device or somehow know which device they are being produced for and adjust their use of Font Styles respectively.
On the other hand, some devices have capabilities which other devices lack, and reducing everything to the lowest common denominator would leave us with the capabilities of TERM, where there is one font and one Font Style ("plain").
It is clear from the WGML Reference that, pre-version 3.33, wgml used a defined set of keywords for font styles:
:DEFAULTFONT FONT PLAIN PLAIN UNDERSCORE USCORE BOLD BOLD USBOLD USBOLD UNDERLINE ULINE ULBOLD ULBOLD
However, it is equally clear from the discussion of the :UNDERLINE block that USCORE, at least, is no longer a keyword and that a :FONTSTYLE for USCORE must be defined if it is to be used.
My theory is that, with version 3.33, these keywords lost their keyword status, and all Font Styles had to be defined explicitly in the the :DRIVER blocks. Since the forms used with the command-line option FONT were likely to be embedded in existing document build systems, while those associated with the :DEFAULTFONT block were entirely contained in the source files for the binary device library, implementations for the command-line set were provided: USCORE and ULINE but not UNDERSCORE or UNDERLINE.
These values (PLAIN, USCORE, BOLD, USBOLD, ULINE, and ULBOLD) most likely constitute a "global set", that is, every driver file is intended to define them (PLAIN always being available if a device cannot do one or more of the others) and so every document is intended to be able to use them.
The source files for some printers or printer families show additional Font Styles being defined. Presumably, these are for use with documents which are written primarily to take advantage of those printers. Examples of these additional values are:
- font names, such as "courier"
- alternative styles, such as "shade", "italic", "ibold"
- document-level styles, such as "index"
- table-of-contents styles, such as "head5"
- physical size styles, such as "size14"
A specific site, such as the Open Watcom build system, may use only a few device/driver pairs (WHELP and/or HELP, PS) for all of its output. In this case, the documents may rely heavily on the styles provided by the device/driver pairs normally used.
