[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
new member
----------------------------------------
Date: Fri, 6 Mar 87 23:31 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Hardcopying 7.0 files from 6-7
To: Juergen Christoffel <unido!gmdzi!jc@seismo.CSS.GOV>
cc: DLW@ALDERAAN.SCRC.Symbolics.COM
In-Reply-To: <8703022248.AA13074@gmdzi.UUCP>
Expiration-date: Fri, 20 Mar 87 23:31 EST
Date: Mon, 2 Mar 87 23:48:57 -0100
From: unido!gmdzi!jc@seismo.CSS.GOV (Juergen Christoffel)
Moin.
I think you misunderstood one point I've made.
Sigh, I don't think you quite understood MY point, but I think we're
converging.
> From: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics.COM>
> [...] Release 6 does not have the information
> it needs to make the decision of what font to use on another device.
To be more precise: it does have the information if you put in the
(undocumented) :HARDCOPY-FONTS: file attribute. This gives a one to one
mapping for the :FONTS file attribute. But that wasn't the reason for
the error listed: the encoding used for Release 7 character styles is
not 'compatible' with Release 6. An epsilon followed by a character is
interpreted as a font switch in Release 6. And those 7.0 header contains
an epsilon followed by a not sign, which is interpreted as a switch to
font no. -43!!! This is due to the representation choosen (not very
careful!) to encode the mappings from Character Styles to epsilon
escapes which are still used inside the files to denote font changes.
If symbolics had either avoided the use of an epsilon with another
semantics or had provided a patch in the 6-7 compatibility package.
That's what I'm nagging about;
The format involved was carefully chosen to achieve upward compatibility
between Release 6 and Release 7 files.
Release 6 had four different implementations of the epsilon encoding.
The Hardcopy-Fonts: attribute did not contain the information needed
to go from the Release 7 world to the Release 6 world, because a file
written in Release 7 does not supply that attribute. If such an attribute
is present, it is left over from a Release 6 version of that file and
is not kept up-to-date. Because of this lack of information, the hardcopy
system could not be converted.
The :FONTS attribute is not used in Release 7 files, either, except for
the sake of commands like c-m-J, where it contrives to keep the
user-interface the same, where possible.
its just sloppy and could have been
avoided without much work.
The only thing that was avoidable here was the error message, the
semantics could not be restored. I'll accept the charge that it was
sloppy not having the compatibility patch make hardcopy signal a
reasonable error.
JC
P.S. I *really* like those machines, but sometimes I have to say it
aloud ...
Thanks.
----------------------------------------