🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.soft-sys.andrew
Article #1301

Postscript Printing Comments? (was) Re: Printers

#1301
From: Robert Andrew Ryan
Date: Tue, 10 Nov 1992 00:00
56 lines
2796 bytes
Excerpts from internet.other.info-andrew: 9-Nov-92 Re: Printers
Bob_Dew@alw.nih.gov (391*)

> Aren't these dependencies necessary to support ATK's "preview"?  

Our intent is to replace preview with code which hopefully will work in
the same process as the document being edited.  Ideally I would like to
see the Postscript printing layout technology leveraged into a true
WYSIWYG editor.  (though I speak only for myself on that one as far as I
know...)  Another less lofty goal perhaps would be a dynamic preview.

Excerpts from internet.other.info-andrew: 9-Nov-92 Re: Printers
Bob_Dew@alw.nih.gov (391*)

> In the long run, I'd think a device-independent troff generator would be
> more useful and less error prone than a direct ATK-->Postscript program.
>  
I disagree, one of the problems with ATK printing currently is that
groff, and the varieties of troff are slightly different in many
respects.  

Another drawback of hybrid ditroff/postscript printing is that it is not
possible to include an inset which prints in troff in an inset which
prints in postscript and have the printing work.  

Perhaps it may be worthwhile for us to investigate another text
formatter besides troff...

Minimum requirements:
1. Documents can include embedded postscript (following the spec for EPS)
2. Font metrics must be  available to ATK apps.  (so they can compute
their print sizes)
3. It must be possible to format text TO embedded postscript (preferably
computing preferred size), and subsequently include this in a document. 
(text or more raw postscript.)

1 is trivial.   2 could be accomplished with gross hackery giving ATK
knowledge of the mapping of troff fonts to Postscript fonts, (currently
we have the technology to read AFM files).
As far as I know 3 is not feasible with ditroff or groff... 

Neither ditroff nor groff is so powerful that I believe we will have
great difficulty duplicating the functionality in a direct ATK -> PS
conversion.  

Ditroff/groff are unattractive also in that you have to pay, or you have
to get and compile gcc (and g++ if gcc <2), and libg++.    Having
followed the groff route for the HP 9000/700 I can say it was pretty
painful.

If anyone has any comments, suggestions on this topic we would be happy
to hear them :-)  

Thanks,
-Rob Ryan
Andrew Consortium
Technical Details
Message-ID: <gezjio_00Woi8milU8@andrew.cmu.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!usc!sol.ctr.columbia.edu!spool.mu.edu!agate!ucbvax!ANDREW.CMU.EDU!rr2b+
References: <keziwcW0ts4j81EkwN@alw.nih.gov>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!usc!sol.ctr.columbia.edu!spool.mu.edu!agate!ucbvax!ANDREW.CMU.EDU!rr2b+
From: rr2b+@ANDREW.CMU.EDU (Robert Andrew Ryan)
Newsgroups: comp.soft-sys.andrew
Subject: Postscript Printing Comments? (was) Re: Printers
Message-ID: <gezjio_00Woi8milU8@andrew.cmu.edu>
Date: 10 Nov 92 00:00:52 GMT
References: <keziwcW0ts4j81EkwN@alw.nih.gov>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 57