Laser-Lovers-Request@WASHINGTON.ARPA (Moderator) (01/09/86)
Info-Postscript for Laser Lovers Digest Wednesday, January 8, 1986 10:31PM
Volume 1, Issue 1
Today's Topics:
Administrative note---Digesting Info-Postscript to Laser-Lovers
Printing Macintosh files on a Laserwriter connected to a mainframe
Re: Printing Macintosh files on a Laserwriter connected to ...
document inclusions
Re: document inclusions
Re: document inclusions
Re: document inclusions
Scribe access to PostScript Accented characters
----------------------------------------------------------------------
Subject: Administrative note---Digesting Info-Postscript to Laser-Lovers
Date: 07 Jan 86 00:55:15 EST (Tue)
From: furuta@mimsy.umd.edu
Info-Postscript@su-score is a list that is devoted soley to discussion of
issues related to PostScript printers.
Some weeks ago, I solicited opinions on whether or not Info-Postscript
should be gatewayed into Laser-Lovers in digest form. It seemed to me that
this would benefit the Laser-Lovers readership, particularly those who don't
have an immediate need for Postscript-related information but who want to
keep acquainted with what is going on in that world. This is also an
acknowledgement of the special role that Postscript is playing in the laser
printer world. (I would feel very little desire to forward a hypothetical
list named something like info-versatec.)
I received a number of different responses to my request for opinions, both
positive and negative. The positive comments pretty much supported the
opinion that I have expressed above. The negative comments came mostly from
people who I would categorize as being experts in the laser printer world.
I believe an accurate summary of their position would be that they already
received info-postscript and had no need nor desire to see the same messages
twice. One negative comment was a bit different, coming from a site that
pays packet charges and therefore having a desire to keep network traffic
levels down.
Based on these comments, I have decided to try digesting info-postscript to
laser-lovers and see how things work out. Each digest will look something
like this one, with a collection of messages, and will have a subject line
something like that on this digest. I hope that this will allow those of
you who get info-postscript directly to pass over these messages without
too much trouble.
I will be working my way through the info-postscript backlog over the
next few days. After this, digests will be put together when there
are enough messages to warrant. In general, they will be spaced at
least one to two weeks apart.
If the info-postscript traffic levels pick up to the point that they are
swamping the laser-lovers list, I will reconsider. I also may reconsider if
the process of digesting the messages ends up taking too much of my time.
I would like to make a closing comment about why it is that I am doing the
digesting of info-postscript. Originally, it appeared that the digesting
duties would be handled by the info-postscript people. After discussion, we
decided it would be best to have digesting done on the laser-lovers side.
The primary reason for this is to try and maintain the separation between
the lists that currently exists. In the past, some of the laser-lovers
traffic has tended to be pretty partisan---extolling the virtues of one or
onother of the laser printer manufacturers or complaining bitterly about
them. The resulting exchanges of messages and differences of opinion have
sometimes been educational and frequently have been amusing.
Info-postscript serves a different role---it's purpose is to allow
Postscript affectionados to communicate with each other in a supportive
environment. I am doing the digesting to try and emphasize that distinction
in roles---laser-lovers is viewing their discussions as a guest.
--Rick
------------------------------
Date: Fri 8 Nov 85 18:31:33-PST
From: Angela Baldo <Anja@SU-SIERRA.ARPA>
Subject: Printing Macintosh files on a Laserwriter connected to a mainframe
I don't know if this is the proper place to post this, but I am
willing to give anything a shot.
At EE-CF we have a laserwriter hooked up to Fuji (a vax running Unix).
The connection is ordinary serial line protocol.
My question is this: Is there any way to print MacWrite, MacPaint,
MacChart, etc. files on the laserwriter? (by putting them into some
form of PostScript that the printer can understand) Printing MacPaint
files which have been untouched since downloading does not work. I
have not tried MacWrite.
There is a program (on Sierra, called "Macimp") which will take
MacPaint files and translate them into Imprint10 so that they can be
printed on a Canon. Is there any such analogous program to translate
the files into PostScript?
Several professors who have received Macintoshes have asked this.
Thanks, for any help/enlightenment you are able to give.
anja
------------------------------
Date: 10 Nov 1985 2329-PST (Sunday)
From: Brian Reid <reid@glacier>
Subject: Re: Printing Macintosh files on a Laserwriter connected to ...
This is not so much a Postscript problem as it is a Macintosh problem.
The question has been answered several times on the INFO-MAC mailing
list; archives of INFO-MAC are kept online on SUMEX, and I assume that
the moderator of INFO-MAC can make one of the copies of the answer
available to you. The summary of the answer is that it is more or less
possible to print Macintosh output on a laserwriter connected to a
mainframe, but that you have to be very careful because a number of
things don't work very well. The reason that they don't work very well
is that (a) the Macintosh uses 8-bit characters in the Postscript files
that it produces, which don't sit well with many conversion programs,
and (b) the Macintosh uses some proprietary bit-smoothing algorithms,
which it downloads into the LaserWriter in encrypted assembly code, in
printing certain kinds of output.
------------------------------
Date: Mon 11 Nov 85 09:18:15-PST
From: Joseph I. Pallas <PALLAS@SU-SUSHI.ARPA>
Subject: document inclusions
It seems apparent that one of the biggest problems with PostScript is
the lack of any standard way to include one PostScript document within
another. Part of the problem, I believe, is in the fact that PS is a
page description language rather than an image description language --
hence, explicit instructions must be included for positioning an image
on the page and indicating the end of a page. These are the two
problems that arise when attempting to nest PS documents.
Has anyone given any thought to this matter or developed any
approaches to dealing with it? One solution to the end of page
problem is to provide the inclusion with an environment in which
/showpage is bound to a null procedure. I'd like to hear of any
approaches to either problem.
Those of us who would like to use PS printers for all our document
needs will need to solve these problems if we want to use a variety of
non-integrated tools in producing our documents.
joe
------------------------------
Date: Mon 11 Nov 85 11:20:14-PST
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: Re: document inclusions
We faced this problem (of nesting documents) when writing a header for
printing generalized postscript files in landscape (two to a page). The
best solution we found (which seems workable) is simply to get the current
deffinition for showpage out of the dictionary stack, save it in your own
dictionary as OLDSHOWPAGE, and redefine showpage to do what you want (calling
the saved procedure when necessary). Since the version of showpage you saved
was the last one that anyone defined, this should allow arbitrary nesting.
evan
------------------------------
Date: 11 Nov 1985 2025-PST (Monday)
From: Brian Reid <reid@glacier>
Subject: Re: document inclusions
The way I've always looked at this issue is that if it has a "showpage"
operator in it, it's a page description, and if it doesn't have a
"showpage" operator in it, it's an image description. If you want to
traffic in images instead of pages, then you need a program that will
put images onto pages so that they can be printed. If you want to
traffic in pages instead of images, then you need a scheme (such as the
one suggested by Kirshenbaum) for disabling the "showpage" in a page
description so that it can be used as an image description.
If you want to store images instead of pages, then you can define a
Unix command called "ppr", "page print", that works like this:
alias ppr echo " showpage " | cat \!\* - | lpr
You use this just like "lpr", except that it tacks a "showpage" at the
end of every image on its way to the printer. Since by definition an
image is always just one page, a single "showpage" will suffice.
If you believe in other brands of Unix besides BSD, you can do ppr with
a shell script instead of an alias.
------------------------------
Date: Tue 12 Nov 85 16:25:25-PST
From: Joseph I. Pallas <PALLAS@SU-SUSHI.ARPA>
Subject: Re: document inclusions
The argument that page descriptions and image descriptions are
complementary, while valid, doesn't move us any closer to a solution
to the problem I posed. As users of PostScript, we need a {\em standard}
for the inclusion of images within documents.
Also, don't forget about the translation issue. Brian's
recommendation for an image-to-page translator (tack on a showpage)
assumes that the image is already positioned someplace reasonable
relative to the default coordinate system (which probably includes an
assumption about the page size). To be included in another document,
an image would need some kind of reference point [everybody that
remembers PressEdit's "solution" to this problem raise your
airsickness bag].
Furthermore, we've seen that the first thing everyone does when
adapting their favorite text or graphics system to produce PostScript
output is to implement an embedded language. How can we merge these
things together? The existing file format standards don't go far
enough in this respect, I believe.
Comments?
joe
------------------------------
Date: 11 Nov 1985 1415-PST (Monday)
From: Glenn Trewitt <trewitt@su-amadeus.arpa>
Subject: Scribe access to PostScript Accented characters
I have generated the required Scribe database files to get PostScript's
accented characters. What I did is:
Generate a new encoding vector that maps the accented
characters into the ASCII alphabetic slots. (all but two,
since there's 28 accented characters and only 26 letters)
This bit of PostScript gets appended to the Scribe
DeviceInitialization string.
Defined strings ala SpecialCharacters for the new characters.
Defined .raw font files for the accented fonts.
Added the facecode "A" to get to the accented fonts,
appropriate for BodyFont and HeadingFont.
The new header is about 2000 bytes longer than the original 870-byte
header. The new fonts use up about 7K of PostScript VM, about 4% of
the available VM on a LaserWriter.
This will allow accents in regular text and headings. I could not
figure out a way to get bolding and italic to work. (One approach
would have been to fill in the ASCII characters from 0-31 with the
accented characters, but 32 isn't enough slots for the 56 available
accented characters.) As it is, the CAPITALIZE environment attribute
will raise the case of all but two of the accented characters. Sigh!
I will post these files one at a time.
accent.lib @string defs and DeviceInitialization
accent.raw width information
xxx.fon .fon modifications to include facecode A
- Glenn
P.S. Sorry about the earlier mis-posting.
------------------------------
End of Info-Postscript for Laser Lovers Digest
**********************************************