Article View: comp.soft-sys.andrew
Article #1301Postscript Printing Comments? (was) Re: Printers
From: Robert Andrew Ryan
Date: Tue, 10 Nov 1992 00:00
Date: Tue, 10 Nov 1992 00:00
56 lines
2796 bytes
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