Laser-Lovers-Request@WASHINGTON.ARPA.UUCP (07/05/86)
Info-Postscript for Laser Lovers Digest Saturday, July 5, 1986 12:27PM
Volume 1, Issue 10
Today's Topics:
elaboration on flow control
Finding the other edges of the paper
Two LaserWriter problems
Re: Finding the other edges of the paper
special characters from scribe
Re: Finding the other edges of the paper
----------------------------------------------------------------------
From: adobe!taft@decwrl.DEC.COM (Ed Taft)
Date: 23 Feb 1986 1513-PST (Sunday)
Subject: elaboration on flow control
In reading the technical documentation on the LaserWriter Plus that was
distributed last week, Glenn Trewitt <trewitt@su-amadeus.arpa> came up
with a couple of good questions regarding DTR flow control. Here are his
questions and my answers.
Q: The update says that there are new signals on the RS232 connector. You
say that the upgrade is just a ROM change. This seems odd, unless
those signals were just never enabled on the old LaserWriter.
A: The DTR and DSR signals have always been there; they simply have not
been used for flow control by the old ROM software. There are two
entirely different conventions for use of the DTR signal. The first
convention (and the one typically supported by time-sharing operating
systems) uses DTR simply to signal the presence or absence of peripheral
equipment. That is, raising DTR means "I'm here" and dropping it causes
jobs to be logged out, modems to be hung up, etc. The second convention
(typically supported by microcomputers) uses DTR to control the flow of
data from the host to the peripheral equipment.
The LaserWriter has always supported DTR according to the first
convention: it raises DTR normally but drops it if the serial channel is
turned off (e.g., to run AppleTalk), the printer is power-cycled, etc.
What is new in the LaserWriter Plus and other PostScript printers is
support for the second DTR convention as an alternative to the first.
Q: The documention talks about flow control in terms of "immediately stop
sending characters" when DTR drops or XOFF is received. How much buffer
space is really left? Many systems just can't stop sending immediately.
For such systems, the response is usually measured in units of time, rather
than number of characters. Therefore the allowable number of characters
beyond XOFF can determine maximum baud rate.
A: The LaserWriter invokes flow control (by dropping DTR or sending
XOFF) when its input buffer is within 100 characters of being full.
This is more than enough to cover hardware data buffering, wakeup
latency, etc., on the host, assuming the host operating system is
handling flow control itself. Of course, problems may arise if the user
program is handling flow control and there is a lot of buffering
between the user program and the serial channel.
Ed Taft
Adobe Systems, Inc.
------------------------------
Date: Wednesday, 26 February 1986 16:37:50
Subject: Finding the other edges of the paper
From: "Cambridge Phoenix - CAM.PHX@CAM.ENG-ICF" <CET1%phoenix.cambridge.ac.uk@cs.ucl.ac.uk>
I have the following problem: for the benefit of a well-known
typesetting program I wish to set up a coordinate system on the LW
with the origin at a point 1in from the top of the paper, and 1in
from the left hand edge. I want to do this without knowing which of
the various device setup procedures (letter, note, a4, legal, ...)
is in effect. I can't see any way of doing it.
I realise, of course, that the LW doesn't actually know the size
of the paper, only the paper tray type. Even so, each device setup
procedure is associated with a certain nominal size of paper; however,
there seems to be no way a PostScript program can determine this size
dynamically. Maybe, as well as having the convention that in the
default coordinate system the origin is at the bottom left hand corner
of the paper, there also ought to be a convention that the coordinates
of the top right hand corner be stored in some canonical variables.
Chris Thompson
Cambridge University Computing Service
CET1%PHX.CAM.AC.UK@UCL-CS.ARPA
------------------------------
Date: Sunday, 23 February 1986 22:36:21
Subject: Two LaserWriter problems
From: "Cambridge Phoenix - CAM.PHX@CAM.ENG-ICF" <CET1%phoenix.cambridge.ac.uk@cs.ucl.ac.uk>
Two LaserWriter problems:
1. The initial graphics state is such that 'currentfont' delivers
a "null" rather than a dictionary. Not only is there no suggestion
in the Reference Manual that this can happen (it just says "Initial
value: installation dependent"), it is also the case that a "null"
passed to 'setfont' causes a typecheck error.
2. This one is more serious. After an otherwise untrapped error (say,
an input wait timeout) the LW announces that it is "Flushing: rest
of job (to end-of-file) will be ignored". However it seems that the
input wait timeout is till operative, and if it goes off again
then end-of-file will be assumed without an EOT ever having been
sent. When some data eventually arives it will be treated as the
start of a new job (and will probably provoke another error!) The
problem seems to be that the "stdin flushfile" in 'execjob' out of
'serverdict' will just jump out of the 'stopped' construction; at
any rate that also explains why no EOT from the LW appears.
This is all with PostScript 23.0, of course. Maybe things are better
in the new version?
Chris Thompson
Cambridge University Computing Service
CET1%PHX.CAM.AC.UK@UCL-CS.ARPA
------------------------------
Date: 26 Feb 1986 1545-PST (Wednesday)
From: Brian Reid <reid@glacier>
Subject: Re: Finding the other edges of the paper
The way I do things like this is as follows. I don't know how accurate
it is (e.g. I've never tried A4 paper) but it seems to work with note
and legal:
gsave initclip clippath pathbbox
/ury exch def /urx exch def pop pop
grestore
This puts the upper right corner coordinates into [urx,ury].
------------------------------
Date: 6 Mar 86 15:37:33 EST
From: OSTROFF@RED.RUTGERS.EDU
Subject: special characters from scribe
Has anyone been able to get the standard text characters with character
codes above 177 using Scribe? The method used for the symbol font does
not work - the maps to coding in a typecase requires specification of
a rawfile. The characters I want are in all the standard text fonts -
and I would like to get them in the current font. Some of the characters
could be coded through the control characters, but there are not enough
places for all available characters. I am considering defining a new font
(called NOFONT, perhaps) and then redefining findfont and setfont to do
nothing if the font name is NOFONT. Is this reasonable? Is there an
easier way. Hopefully I have just missed something obvious.
Thanks for any ideas.
Jack (OSTROFF@RUTGERS or
OSTROFF@RED.RUTGERS.EDU if you like domains.)
------------------------------
Date: Friday, 7 March 1986 15:54:56
Subject: Re: Finding the other edges of the paper
From: "Cambridge Phoenix - CAM.PHX@CAM.ENG-ICF" <CET1%phoenix.cambridge.ac.uk@cs.ucl.ac.uk>
Thanks to everyone who suggested using variations on "initclip clippath
pathbbox" to find the top right hand corner of the paper. However most
of these solutions only find the top right hand corner of the imageable
area, rather than of the paper. On the other hand, Ann Robinson from
Adobe has pointed out to me that if one assumes that the imageable area
is centered on the paper, and that the bottom left hand corner of the
paper is at (0,0), then one can deduce the coordinates of the top right
hand corner of the paper by adding the low and high coordinates returned
by 'pathbbox'; e.g.
gsave initclip newpath clippath pathbbox grestore
3 -1 roll add /ury exch def add /urx exch def
I should warn that this procedure doesn't accurately give, for example,
11" and 8.5" for 'letter': there are deviations of the order of a pixel.
Chris Thompson
CET1%PHX.CAM.AC.UK@UCL-CS.ARPA
------------------------------
End of Info-Postscript for Laser Lovers Digest
**********************************************