Multi Font Files and Release 6-7

["Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>]

    Date: Wed, 3 Dec 86 03:12 EST
    From: Jeff Gibbons <jeff@JASPER.Palladian.COM>
    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.
Actually, this statement isn't quite right.  We made ever attempt to
do just this.  I haven't seen any bug reports that this doesn't work
since about 1982 or so.  I'm sure you really encountered a problem,
of course, but ...

    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.  
... but perhaps it only occurred when compiling the file, not when
reading it into the editor?  Reading into the editor and compiling
used two very different implementations, and it's possible that the
bug fixed in 1982 didn't get fixed in both places.  Actually, I'd
say it's probable, since I think I fixed it in the editor in 1982,
and in 1982 I don't think I even knew about the other place.

    In Rel 7, the whole idea of fonts changes and there is surely a lot of new code to
    support this fact.  

That's an understatement.  The Release 6 code has been excised, root,
branch, and leaf.  The Release 7 format is considerably more complex,
containing more information, more room for extension, and with more
extensions coming.  Many of the concepts have no equivalent on TI
machines, of those that do, some can't be put in files on TI machines,
and some are only rough equivalents.  However, if someone wants to,
there is enough information for a TI machine to pick the right font
to display, in the case of the standard character set.  You couldn't
use the rel-6-7 compatibility code directly, but it illustrates the
technique.

			Perhaps it is not as robust against * as the old code was
    (to whatever extent that was).

I don't know about "as robust"; it just sounds like it has a different
bug.  If someone would be willing to mail me a short TI file that
causes the bug, that's self-explanatory as to what it's supposed to
look like, I can see about getting it fixed.  If you do it very quickly
it may even be in the next release.

    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.

By the way, you might suggest to TI that they stop writting *.
It only makes things more complicated and less robust and maintainable.
It doesn't make files any shorter, and makes them harder to read by hand
if you ever need to do so.  In sort, it was a bad idea we flushed 5 years
ago, and perhaps they could be persuaded to do so also.