Multi Font Files and Release 6-7

[Jeff Gibbons <jeff@jasper.palladian.com>]

    Date: Tue, 25 Nov 86 14:18 CST
    From: David D. Loeffler <Loeffler@MCC.COM>

    Thanks to this note from Bob I have been able to fix the multi-font
    problems I mentioned in a previous message.

	Date: Sat, 15 Nov 86 17:34 EST
	From: RWK@YUKON.SCRC.Symbolics.COM

	...

	2)  Symbolics software *NEVER* writes *'s.  That's something
	    written by Explorer and LMI software.

	...

    Well, the *'s would be put in by the LMI's (in places I could not
    determine the reason for) and then when reading the Symbolics would
    interpret it as a shift to fontN where N could be any one of the fonts
    for the file then it seemed like 1 would use the next font in the font
    map and so you can image the strange looking file that would result from
    these semi random font changes.

	...

    I retract this statement.  If you have multi-font files and are moving
    them between LMI's, TI's and Symbolics then be forwarned that the *'s
    may cause serious problems.  I seem to have fixed the problem by forcing
    the LMI's here to use 0 instead of *.


      -- Dave

We have many Symbolics and TI machines and we ran into problems with
fonts in source files many months ago (all of this in Symbolics 6.0 or
6.1, I can't remember which). The source of our problems was also *,
albeit with different manifestations.

 in a file denotes a font shift and the next character denotes which
font to shift to. On a Symbolics, this second character is presumed to
be the index into the font map represented as an ASCII 0, 1, 2, etc (ie.
character code 48, 49, 50, etc). A file is further presumed to begin in
the default font 0 and remain that way until an explicit shift is
encountered. Files often shift to another font briefly and then return
to the previous font (usually the default font again). Thus one might
find 1FOO0 when just FOO has been put in font 1.

TI (and apparently LMI) use a similar but not identical scheme. The
difference is that they add * as a special character in font shifts. The
semantics of * is to shift to the PREVIOUS font; that is, the font that
was in force before the last font shift. For the FOO example, one will
find 1FOO*. A stack model is used so that beginning in font 0, when
Symbolics might write ZERO1ONE2TWO1ONE0ZERO to see the font change
twice and then back, TI will write ZERO1ONE2TWO*ONE*ZERO. Note,
however, that ZERO1ONE02TWO01ONE0ZERO would give you the same
visual effect).

Since TI's interpret a superset of the shifts that Symbolics will use,
they will read files correctly. But since Symbolics interprets a subset
of what TI's will use, they can have problems. Of course, Symbolics
could interpret the same superset and only write the subset but that
would be too easy for all of the users.

Now this doesn't really explain all of the phenomena you describe. For
example, why did you only encounter problems once you went to Rel 7 and
6-7 compatibility? Why no problems with Rel 6? Well, Rel 6 probably
treated the * differently in different parts of the system code.  We
had no problem in ZMACS with the fonts. As best I can remember, our
first problem occured in compiling a piece of code which I hazily
remember involved some system reader macro. Some chunk of code
interpreting the font shift so strongly assumed the next character would
be a numeric index that it blindly subtracted the character code for 0
from its character code. If the assumption is true then you end up with
the correct result, eg. (- (char-code #\1) (char-code #\0)) = (- 49 48) = 1.
But if that next character is * then you get (- (char-code #\*) (char-code #\0)) =
(- 42 48) = -6 which is a rather undesirable font index. It blew us out of the water.
But maybe such nasty spots only persisted in relatively obscure parts of the system
as was our case.

In Rel 7, the whole idea of fonts changes and there is surely a lot of new code to
support this fact. Perhaps it is not as robust against * as the old code was
(to whatever extent that was).

It's also pretty obvious why changing * to 0 does (mostly) the right thing. As
mentioned above, the most frequent case is changing from the default font and then
back to it. So * typically means 0. But this needn't be the case as the previous
font might have been something else.

Jeff Gibbons