WGML Macros and User Defined Tags

Introduction

This page is concerned with some obscure behavior noted when implementing wgml.

These items which would have been treated as bugs and fixed, except for the fact that they appeared in the output files, and so had to be duplicated. Note that concatenation was on in all cases. After our wgml is firmly established, they should probably be reversed to improve the appearance of the documentation.

Unexpected Space Insertion

Of these items, one of the hardest to sort out turned out to be unexpected space insertion. In effect, wgml 4.0 makes up its own mind to insert a space under certain conditions, with no assistance from the document author.

To see why this is a problem, consider a two-column list formed with tabs: if some entries in the second column are text and some are macros, then the entries produced by macros may (and often will) be one space further to the right than the one produced by text. Since the second column position is specified by a tab stop, this means that the output produced by the macros will appear to be paying no attention at all to the tab stop.

This behavior is controlled during the processing of text phrases, as an extension to retaining a space if the phrase starts with one and inserting a space if it does not but is at the start of an input record. These phrases may come from a file or a macro (which in turn may or may not be invoked using a user tag). The immediate result of this processing is to form the text phrase into output lines, which are then formed into paragraphs.

These conditions apply in all cases:

1. This is not the first phrase in the paragraph.
2. Concatenation is ON.
3. Control word CT is not in effect.
4. The phrase is not inside an example (a block bounded by tags XMP/eXMP).
5. There is no already-computed space value to use.
6. The current horizontal position is to the left of the final horizontal position of the prior output line.

User tags invoke a macro, and one of the surprises was that how that macro is treated depends on whether it is invoked directly or through a user tag. A related surprise was that the effect of the user tag option "continue" can be distinguished from those of control word CT.

A space will be unexpectedly inserted if a user tag is being processed and the "continue" option was not used. In this case, the width of the space will depend on the font to be used with the current phrase.

For macros not invoked through a user tag, two separate criteria apply:

1. Both the font to be used with the current phrase and the font used with the previous phrase are not 0. In this case, the width of the space will depend on the font to be used with the current phrase.
2. The phrase is the first phrase in the macro and either of these conditions is true:
   1. The font to be used with the current phrase is not 0;
   2. The font used with the previous phrase is 0.

In the second case, the width of the space will be that of font 0.

I should point out that, so far as I can tell, "font 0" is literally correct, but the value of attribute font of the DEFAULT tag in the LAYOUT section may actually be what is used. Unfortunately, wgml 4.0 sometimes behaves oddly when that value is not "0", and, since the Open Watcom documents all use "0" for that value, it is hard to be sure what is actually going on.

To illustrate the final criterion, which was very hard to identify, consider this text:

.co on
.tb 1 15
.tb set $
.dm temp2 begin
:SF font=4.>:eSF.
.dm temp2 end
:SET symbol='ISO1'   value=';.ct;.temp2;.ct'.
.dm temp3 begin
$ISO2$:SF font=4.>:eSF.
.dm temp3 end
:SET symbol='ISO2'   value=';.ct;.temp3;.ct'.
.dm temp4 begin
$ISO3$
.dm temp4 end
:SET symbol='ISO3'   value=';.temp4'.
.br
$ISO1$&ISO1.
.br
&ISO2.
.br
&ISO3.&ISO1.

which (at least in its original context) produces:

ISO1            >
ISO2           >
ISO3            >

because only ISO2 incorporates the "ISO2" text phrase into the macro. For ISO1, it is normal text; for ISO3, it is different macro; in both cases causing an unexpected (and unwanted) space to be inserted.

A Related Case

Tags which start at the beginning of a physical input record and which are followed (in the next physical input record) by control word CT insert a space anyway. What appears to happen is this: the prior physical input record's end-of-line character is converted into a space and this space is kept, while the CT applies to the similar space created from the end-of-line character of the physical input record in which the tag appears. This space is also unexpected, but it is not produced through the same mechanism, so far as I can tell.