[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Multi Font Files and Release 6-7
- To: Slug%utexas-20@MCC.COM
- Subject: Multi Font Files and Release 6-7
- From: "David D. Loeffler" <Loeffler@MCC.COM>
- Date: Tue, 25 Nov 86 14:18 CST
- Cc: RWK%Symbolics@MCC.COM, Loeffler@MCC.COM
- Character-type-mappings: (1 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI") (2 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") (3 0 (NIL 0) (:SWISS :BOLD :NORMAL) "HL12B") (4 0 (NIL 0) (NIL :BOLD-ITALIC NIL) "CPTFONTBI")
- Fonts: CPTFONT, CPTFONTI, CPTFONTCB, HL12B, CPTFONTBI
- In-reply-to: <861115173459.1.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
- Postal-address: P.O. Box 200195, 9430 Research Blvd., Austin, TX 78720
- Reply-to: Loeffler@MCC.COM
- Resent-date: Mon 1 Dec 86 00:31:52-CST
- Resent-from: <CMP.SLUG@R20.UTEXAS.EDU>
- Resent-message-id: <12259235497.10.CMP.SLUG@R20.UTEXAS.EDU>
- Resent-to: SLUG:;
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
0) Files written under Rel-7 and rel-6-7 are not 1supposed
0 to be readable under Release 6.1. The whole point is
that you're supposed to load it into 1all0 of your Rel-6
systems to avoid compatibility problems.
1) We have been using Rel-6-7 in-house for a year now.
That doesn't mean there can't be a bug, but it isn't
so broken that I don't think your message likely did
more harm than good. The risk certainly justifies
quick investigation, but I think it's better to take
the time and investigate what the problem really is,
rather than have several thousand people who've already
loaded it wondering "oh, no, what have I done?".
Obviously, that's not how it appeared to you at the
time, of course, and it's a judgement call no matter
how you look at it. It's quite possible that after we
get this figured out, I'll come to the opposite conclusion,
I just think it is rather 1improbable0.
2) Symbolics software *NEVER* writes *'s. That's something
written by Explorer and LMI software.
This bit of information allowed me to isolate the problem and make a fix
to the LMI software that seems to be working. The problem is that the
* is written by LMI's (we are running release 3) in place of the 0.
Note: it is not a one-to-one mapping which is interesting. Then when a
Symbolics would read the file it would not interpret the * in the same
way an LMI would. The problem was difficult to pin down because the
Symbolics would correctly interpret the *'s until there got to be too
many of them. The odd thing is that the problem never surfaced in
release 6.1 until rel-6-7 was loaded. But since Symbolics never really
supported * it was only a matter of time before their interpretation
and LMI's would diverge.
3) Rel-6-7 does not patch the code which 1generates0 the epsilon
codes; it only patches the code which 1interprets0 them.
(Don't be faked out by the fact that it patches a 2:tyo
0 method. That's used as part of interpreting the input,
not as part of generating the output. Weird, eh? A holdover
from the MIT days of long ago).
This helped too.
4) You don't say what what happens when it fails to read properly.
What would happen is when a file was read with too many *'s was read?
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.
5) You don't say that you observed that when you had it in the
machine with rel-6-7 that it appeared correctly there. (I.e.,
did you verify that it isn't a problem with 1reading0 files in
rel-6-7 instead of a problem with 1writing0 them?)
The problem came from reading the files in but I could not isolate the
problem to whether the LMI was putting in * in the wrong places or if
the Symbolics was interpreting them differently. I just forced the
LMI's to use 0 instead of * and now all seems to work correctly.
The evidence you cite contradicts # 2 and 3 above. This apparent
contradiction would seem to be the primary focus for investigation.
Possibilities that come to mind which would also explain #1 are
that rel-6-7 is misinterpreting a file written by Explorers, or
that you have a private patch that relates to Explorer files.
Actually we have been editing multi-font files for some time on both
LMIs and Symbolics. It was only after rel-6-7 was loaded that the font
information got skewed.
What's really needed is a file which when read into Rel-6-7 and
written back out again, fails in the manner described. Surely,
if you've observed it, you have such files lying around?
The failure was not that Rel-6-7 could not write out and then read in a
file. It was just that the file was alternately edited on a Symbolics
and LMI. After the number of font changes grow to large then the file's
font information would get skewed.
Date: Wed, 5 Nov 86 08:49 CST
From: David D. Loeffler <Loeffler@MCC.COM>
Date: Tue, 4 Nov 86 06:38 CST
From: David D. Loeffler <Loeffler@MCC.COM>
In Symbolics 3645 3Release 7 Problems0 in Genera 7.0, Mailer 5.2,
IP-TCP 52.0, microcode 3645-FPA-MIC 394, FEP 127,
Machine serial number 4864,
h:>loeffler>patches>release-7>mcc-electric-lisp-mode.lisp, on Dave's HAL 9000:
We are having 4SERIOUS0 problems with Release 6-7 and multi font files.
Our group has 51 Symbolics machines. 2 are running release 7 and the
rest are running release 6.1 with Rel-6-7 loaded. All of our code
development uses multi font files and now we have found that the systems
running Rel-6-7 have their own way of writting out multi font files so
that they can not be read correctly from Release 6 or Release 7. These
files can be read correctly only from other machines running release 6.1
with rel-6-7 loaded.
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 *.