[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>
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)


    I think you misunderstood one point I've made.
Sigh, I don't think you quite understood MY point, but I think we're

    >   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.


    P.S. I *really* like those machines, but sometimes I have to say it
	 aloud ...