Re: JUSTIFYING HEADERS/FOOTERS

[ROBERT HOLMGREN]

Naw, don't use Tabs! You won't get a true physical centering of text no matter
what length! This is a real lacuna in XyWrite, but it can be overcome, rather
easily too (though XyQuest has told me before that it can't be done -- silly).
Here's the principle, and then the trick.

I assume you have a decent printer? One that distinguishes between CR and LF?
OK, the idea is to combine the LeaDer command with an LS=0 command. I use a
brief routine to slap a template into text, then I fill in the text (see
nclosed LCR.PM, which is actually set up as a Type C Help routine, but you
can make it a disk-based PM or whatever you wish). This, in general, is what
the result text will look like (assumption: your "normal" LS LineSpacing
command is LS=2):

 ≪LS≫left≪LD ≫right{3-byte_Ascii-13 followed by normal CR}
 ≪LS2≫≪FC≫center
 ≪FL≫

 The 3-byte Ascii-13 is the sixteenth-note symbol -- you *need* that to force a
CarriageReturn without a LineFeed. Note that LS=0, which you can code as
either ≪LS≫ or ≪LS0≫, does not increment the line counter and therefore has
no effect on PL PageLength or FD FormDepth values.

 But now comes the wrinkle that many users would need to watch, involving the
Width Table. Most Width Tables (especially those from XyQuest) are sloppy.
They table long and short characters, while the middle class take a 'Standard
Width'. It's a stupid shortcut. A proper PS Width Table should table *every*
printing character; then it should have an additional line that says 'SW=0'
StandardWidth=0. That forces any *non*-printing character (any char not in the
font) like BackSpace, CarriageReturn, LineFeed, Nul to get zero width. This
becomes important when you issue 3-byte chars like the sixteenth-note
(Ascii-13), because XyWrite treats them as if they're *printing* characters in
its internal calculations, even though they're sent to the printer as 1-byte
chars and can't be printed (sometimes they can, of course, but in that case you
gottta issue special code to force e.g. a CarriageReturn *symbol* to be printed
instead of *performing* a CR, so that's an irrelevant situation). If SW=10,
your 3-byte 13 is gonna grab 10 width units. Whereas you want it to have --
and it deserves -- 0 width units. XyQuest never thought this out clearly.

Likewise, fixed fonts usually have a Width Table like this:

 WD:10PITCH
 SW=30
 ET

That should always be modified, somewhat as follows:

 WD:10PITCH
 SW=30
 <0><7><8><9><10><13><26><27><255>=0
 ET

 (Actually, I just table 8-9-10-13, because they're the ones that get in my
way.) If you don't do this, a 3-byte Ascii-13 will grab space.

*Enclosed File: LCR.PM