chuq@plaid.UUCP (04/30/87)
Desktop Publishing Archive #4 Subjects: Getting figures into TEX documents version 3.0 of ready set go - any comments? Re: Postscript & Frame Re: Getting figures into TEX documents Re: Postscript & Frame Mac to Sun File Transfer Re: Mac to Sun Mac Prices Re: Mac to Sun File Transfer Re: MAC to Sun File File Transfer. Publications System Priorities OmniPage on the Sun. PostScript and previewing and the future of Window Systems -------------------- From: <blit!jon> Jonathan Ryshpan Subject: Getting figures into TEX documents Is there a convenient way to insert figures generated on other machines into TEX (or troff) documents. A natural way to do this would be to generate a file in some kind of general format (say PostScript), which would be merged into the document. A Mac can easily generate such files. If TEX is also generating generating PostScript output, it should be easy to merge the figure into the desired place. In principle, the size of the figure could be adjusted to the amount of space reserved in the document with a few lines in a PostScript header. Are there any tools available to simplify this? Jonathan Ryshpan USENET: hplabs!nsc!blit!jon National Semiconductor ARPA: decwrl!nsc!blit!jon@ucbvax.ARPA Sunnyvale, CA -------------------- From: dsc@seismo.css.gov (David S. Comay) Subject: version 3.0 of ready set go - any comments? i just received in the mail a blurb on the latest version of `ready set go' from manhatten graphics, version 3.0. i would appreciate hearing any comments regarding this new version and how it compares with pagemaker and macpublisher. thanks in advance. -------------------- From: cae780!tektronix!tekcrl.TEK.COM!larrym Subject: Re: Postscript & Frame In a previous message set there was some confusion about developing PostScript drivers vs PostScript interpreter and imaging model. In trying to clarify this confusion "S Page" at Sun (spage@sun.COM) made the following statement: > The latter (implementing the PostScript interpreter and imaging model) > is incredibly difficult. No one but Adobe has a PostScript interpreter > running, although a few research implementations are in progress. I thought I should add that this is not quite true. In fact there is a local (Portland, OR) company named Control-C Software which makes and sells a PostScript look-alike called C-Script. Naturally, their market is mainly printer manufacturers rather than end users. They were mentioned in an InfoWorld (I think) special article on desktop publishing sometime about two months ago. They didn't take that long to develop the product, so it must not be that difficult. And it shouldn't be, threaded interpreters and graphics transformations are well known entities. Naturally, this is not to belittle the effort that it does take to get them right. Larry Morandi P.S. I have no affiliation with Control-C Software, and this should not be interpreted as either a testimonial or as an advertisement. -------------------- From: Jean-Francois Lamy <lamy%utai.toronto.edu@CSNET-RELAY.ARPA> Subject: Re: Getting figures into TEX documents I have the necessary stuff to include Macintosh illustrations into TeX documents. This required hacking the dvi2ps device driver and a special prologue file. Rotation, Translation, Scaling and Clipping of the included images is supported. I am reluctant to broadcast this as I know that a new version of dvi2ps is in the works. unix-tex@washington.arpa is probably a better forum for this discussion. -------------------- Subject: Re: Postscript & Frame From: larrym%crl.tek.csnet@CSNET-RELAY.ARPA In a previous message set there was some confusion about developing PostScript drivers vs PostScript interpreter and imaging model. In trying to clarify this confusion "S Page" at Sun (spage@sun.COM) made the following statement: > The latter (implementing the PostScript interpreter and imaging model) > is incredibly difficult. No one but Adobe has a PostScript interpreter > running, although a few research implementations are in progress. I thought I should add that this is not quite true. In fact there is a local (Portland, OR) company named Control-C Software which makes and sells a PostScript look-alike called C-Script. Naturally, their market is mainly printer manufacturers rather than end users. They were mentioned in an InfoWorld (I think) special article on desktop publishing sometime about two months ago. They didn't take that long to develop the product, so it must not be that difficult. And it shouldn't be, threaded interpreters and graphics transformations are well known entities. Naturally, this is not to belittle the effort that it does take to get them right. Larry Morandi -------------------- From: frame!djm Subject: Mac to Sun File Transfer This group seems to have lots of sun/mac users so the following questions seems appropriate here: What is the best way (ie. cheapest and yet reliable) to transfer mac 8-bit files (MacPaint & Resource files) to a Sun? Is there a public domain unix package that handshakes with MacTerminal or some similar arrangement? Any info will be greatly appreciated. Thanks. David. sun!frame!djm -------------------- From: dbruno@opal (Dennis Bruno) Subject: Re: Mac to Sun Mac Prices 2 The info on Mac/Sun transfers would be greatly appreciated! I have done furhter research on Mac Prices and have found Stanford to be far and away the cheapest. As of Sept 1, they have the following: Mac 512K E $929 Competition is over 1100 Printer $393 Thanks for all your input. Now I only have to pay the $9K tuition to be a grad student to get the price... Den -------------------- From: ssp@polar (S.Page Tech Pubs-windows 691-7671) Subject: Re: Mac to Sun File Transfer I've used mac kermit and UNIX kermit, and MacTerminal together with the public domain programs macput/macget. There are also public domain programs that will let you convert Mac fonts to Sun vfont format screen fonts, convert MacWrite documents to troff, print MacPaint documents on a UNIX PostScript printer, and print any Macintosh file on a UNIX PostScript printer. I got all these programs off the USENET net.micro.mac news group and the INFO-MAC digest. Any good local users group should have them all. Does anyone have a program that converts MacPaint files to Sun rasterfile format, and/or vice versa? -------------------- Subject: Re: MAC to Sun File File Transfer. From: munnari!yarra.OZ!richb@seismo.CSS.GOV >What is the best way (ie. cheapest and yet reliable) to transfer mac >8-bit files (MacPaint & Resource files) to a Sun? This question is probabily going to be answered about a dozen times by the time my mail arrives uphill from Oz. Still.. We use MacKermit on the Mac and C-Kermit on the Sun to transfer MacPaint files to the Sun. These are public domain, available from Columbia Uni. I would imagine there are several people at Sun Microsystems who should be able to give you a copy of these. We use one of the small filter programs that came with Solar Paint, that converts MacPaint files to Sun rasterfiles, where they are tidied up, then put into your Frame Maker program. MacKermit also allows the Mac to connect to the Sun as a terminal session for running Unix jobs (just like MacTerminal). -------------------- From: dirk@words (Dirk van Nouhuys) Subject: Publications System Priorities Recently at Sun we have been discussing what features we would like in a publications system. Henry McGilton assembled a list of features and I took it upon my self to rank them in order of value to making Sun manuals as I see it. The result follows. It is skeletal because it depends on various previous discussions and documents that are not available, and is not completely consistent, but I but I hope it will be stimulating anyway. Priority numbers: 1= Sine qua non 2= Highly desirable 3= Clearly desirable, but we could do without it. 4= Barely worth room on the disk for the executable code. In keeping with my attitude that we should make intelligent tradeoffs, I have tried to give high priorities only when really necessary. But any system that offered only a small portion the 2's would not be attractive. Some General Qualities: Robust [1] (does not break down, requires little upkeep) Easy to learn [2] Easy to use [1] In connection with ease of use note that this list is incomplete with respect to user interface. Functions are not the whole issue. I recently used a spelling checkers that would fit the functional spec below, and was also virtually unusable. Run on Sun Machines [1] Run Inside SunView [2] Henry comments that you can't expect everyone to to learn a new interface. I think learning new interfaces is a way of life. Open to UNIX [2] The only reason a publications system needs to be open to UNIX is to get publications services from UNIX. If it supplies a sufficient services there is no need to be open to the operating system. Of course it must be able to accept ASCII text, see below. Support a Standard Page Description language [2] Ability for the User to Inject Chunks of the Page Description Language in to the document [3] Provide real document management [1] That means something vaguely like SCCS so everyone knows which is the official copy, who has done what to it when, who is responsible for what, and where the schedule stands. Notion of textual elements [2] An internal markup language is one method, data base type storage is another, see below. Templates [1] Automating numbering of pages and outline elements [1] Access to structure elements including outline [2] (See under text editing below) Automatic Cross referencing [3] Support for bibliographic Materials [3] Revision bars [2] A comparator is one way, perhaps not the best, another way is a data base structure, see below. Flexible page design including wide margins where I can put text or figures and recto verso pages [1] Note however that columns beyond 2 is a [4] Separate Page design for first pages etc. [2] Control of Widows and orphans [2] Text runarounds [3] Control over display elements [2] Footnote Support [2] Small capes, ligatures etc [4 except for accents, 3] Access to any fonts [3] User Control of Kerning Tables [4] Sophisticated layout of tables [1] Automatic Tables of contents [2] Automatic indeces [1] Importing object oriented graphics [1] Importing pixel oriented graphics [2] WYSIWYG Formatting and editing [2] Integrated text and graphics [1] Produces camera-ready copy [1] Document Description via external database. This is a means rather than and end. This function, being for the user and the system to be able to manipulate text elements by types, and have those elements be the basis of templates, is a first priority. An alternative and in some ways superior method of doing it is by storing the text as variable-length records in a data base structure as in Tymshare's Augment system, ThinkTank, and Framework. See comments on sidebars below. Typography: Small Caps [3] Ligatures [3], custom ligatures [4] Droped, raised, hung caps [4] Accents [2] Change case [3], should be and editing command. Typeface distortions [4] Letter and word spacing. Manual kerning [4] Automatic kerning [3] Word spacing [4] Letter spacing [4] White space reduction [4] River reduction [4] Ladder reduction [4] Body Copy Select face, size, leading, linelength [1] Select lines per page [2] Columns per page: 2 columns rates [2]; more than two columns[4] Select gutter width [3] Insert rule [4] Select face & size for Headlines [1] Headers/ Footers Select Face and size [1] Automatic Page Numbering [1] Continue/From [4] Footnotes and Endnotes (on style sheet) Select face and size [2] Automatic keying to pages [2] Indents (in style Sheet) Automatic [2] Hanging indent [3] Tabs (in style sheet) Set hard tabs [3] Set decimal tabs [3] Math [3] Hyphenation [3] (We use a ragged right format where hyphenation is unnecessary. In the context of many programming languages where the hyphen or underbar is meaningful, hyphens are confusing] Rule based. [5] Rule-based hyphenation is ugly and if we have hyphenation we have the resources to use a dictionary. User parameters for hyphenation, if hyphenation at all [2] Manual justification [4] Layout: Style sheets are a 1; between graphic and input form, graphic are preferable for most purposes. Graphic Integrations Bring in scanned image [2] Bring in Drawn Image [1] Reflow text around images [3] Flow text into arbitrary shape [3] Rulers Scales [1] Grids [2] Scroll [1] Zoom [4] Overlays [4] (Overlays are mostly of interest for color and we are not doing color.) Copyfitting [3] Notepad [2] Recto Verso (in Style sheet) [1] Comps [3] Rules (stylesheet) [2] Pagination Widow and Orphan suppression (style sheet) [2] Vertical column justification (style sheet) [4] Page numbering (style sheet) [1] Automatic reformation of recto/verso [1] Signature planning [3] European Page Size [4] Supplementary Material Automated Production of Reference Tools ["Intelligent Text"] Indexing. [1] (I agree with Henry that a program that simply indexes envery instance of a word is a not a good idea; for example to index under IBM the phrase "unlike IBM" is a disservice to the reader. The writer must be able to mark the keywords one by one by judgement.) Automatic table of contents [2] Automatic cross references [2] Automatic footnotes [2] Automatic Table of Illustrations or Tables [3] Automatic paragraph and indentation numbering [1] Automatic Line numbering [3] Automatic highlighting of indexed words for reference as you work [2] Levels of Indexing. I disagree with Henry and I think the writer should get to decide, but more than 3 levels is a priority [4]. Automatic Collating terms different from printing terms [2] Automatic Page ranges [2] Principal page identity [2] Collating Sequences: I agree with Henry: having them for other languages is a [4]. Layout. I think the index style sheet should be part of the document style sheet. Text Entry: Text may be imported as ASCII files [1] Import gencoded text [3] Import text with word processor format codes [3] Keyboard entry of text. This section begins with the phrase I imagine a system that is the only one a writer normally ever uses. No bounding from editor to this to that. One system with one, integrated command interface. Some people will want to stick to their favorite editor, and provision for that is useful, but I would hope the system would be good enough that use of other editors would fade away. This image is very important to of ease of learning and ease of use. For that reason strong text entry and editing [see below] features are [1] for me. Text Editing: Autoupdate of imported text file [3] Text Manipulation: User specified Keyboard combinations [3] String searches including Wild cards and non printing characters [1] I would like to add The ability specify in string searches types of characters as a class, e.g. ^VC for upper case, ^Vn for number ^Va for alphabetic, ^Vnp for non-printing. [3] Searches must be able to find non-printing characters, both spaces and CR/LF and control characters.[2] A little ifing in replacement would be very handy, i. e. if upper case replace, if not don't. [3] This system should be able to recognize for the purpose of deleting, copying, inserting, and moving the following things:[2] Headings Branches of trees, that is a heading and everything dangling from it. Paragraphs Sentences Words (alphabetic strings bounded by non-printing characters or punctuation). Printing strings (strings of printing characters bounded by non-printing characters, for editing programs). A transpose command, where you select two items and transpose them, is very useful. Many typos are transpositions of letters, many steps in revision are transpositions of words sentences, or subsections.[3] Automatic CR at the end of the specified line length [1] It is often useful to be able to select such entities that are not on the screen, as by outline number and or string search. E. g. to select a point on screen and execute command that moves the next third level heading and its dependencies that contain the word Grunt to this spot. [3] As with sidebars, features like this are easier to implement when the text is stored in a data base structure. Speller [2] The user should be able to specify exceptions both in a main dictionary and unique to a document. The speller should operate by highlighting the words in the text and offering the option of the user typing in the correction or asking for guesses. Guesses should optionally be based on phonetics or letter trans position and lookup. It should toggle suffix and prefix stripping. Dictionary definitions [3] Thesaurus [3] Graphics An object oriented drawing package of the MacDraw type [1] A pixel oriented painting package of the MacPaint type [2] Tabular Layout Overall Specify Position of Table [1] Draw a frame around a table [1] Stretch Table to fit measure [3] Column Format Select Fonts for Columns [1] Select point size for column [1] Select leading for column [2] Select column width [1] Column Layout Left Flush, Right Flush Centered [1] Numerically Aligned Columns [1] Spanned Columns [2] Vertical Spanning [2] Vertical Staggering [3] Rules between columns and rows [1] Tabs Left Flush, Right Flush, Centered [1] Set in ens and ems [2] Set in any convenient Unit [3] Even division of lines [3] Dynamic tabs [2] Mathematical Typesetting [3] Revision Bars [2] Note that where you have text stored in variable-length records it is easy to include a time stamp on the record and then set up a search mechanism to show bars as needed. This seems to me much less awkward than a comparison program, which depends on orderly retension of previous files, possibly several previous files. Output/Input Postscript [2] Other page description languages [3] Scanner support [2] Printing selected parts and multiple copies [2] -------------------- Subject: OmniPage on the Sun. From: munnari!yarra.OZ!richb@seismo.CSS.GOV Gene Hall of Datacube, Inc. on Oct 2 in this mailing list, mentioned Omnipage, a publishing software package for the Sun. Gene (or anybody else), can you give me an address plus a contact name for this package? A telephone (and/or) FAX number would be nice. -------------------- From: ssp@polar (S Page [Tech Pubs {windows}] 691-7670) Subject: PostScript and previewing and the future of Window Systems In a previous message I said > No one but Adobe has a PostScript interpreter running, although a > few research implementations are in progress. Sun had been researching an extensible window system architecture based on a subset of PostScript(tm of Adobe Systems, Incorporated) for two years, called SunDew. At the recent Sun Users Group meeting in Washington (BTW, Frame Maker "almost 1.0" and the Palantir Compound Document Processor were the hot electronic publishing products, to my eyes), Sun announced the product of that research: NeWS, a Network extensible Window System. The rest of this posting is self-serving rabblerousing from an involved observer, but I think it may be of interest to readers of this mailing list. Needless to say, these are my opinions, not my employer's. Bill Joy summed up the impact of a PostScript-based window system when he said ``There was ASCII compatibility between the terminal and the printer, but when we went to bitmap we somehow lost it. NeWS brings it back.'' Since NeWS runs PostScript, a true PostScript page previewer is a trivial program (create a window then send the PostScript page description, scaled to the window size) . If any WP, graphics or page layout program can generate a PostScript output file (are there any left that don't?), you can view its output on-screen. Suddenly the on-line library of the future is a fait accompli. You ask for some encyclopaedia article, and are sent the PostScript for it; it's up to you whether you see it on your screen or send it to the printer. There's no distinction between the on-line version of a book and the printed version besides their different resolutions. NeWS is also a networkable window system. Programs running on a remote computer (the Cray at the local library, say) can send PostScript over the wire (serial link, Ethernet, modem, whatever) and it will create windows and display stuff on your home computer. Because NeWS is extensible, you can define primitives that allow the data compression that makes the remote performance acceptable. The NeWS development team had a prototype version running on an Atari over an RS-232 link from a Sun. NeWS is an interpreted, extensible language, hence it's interactive. If you've ever connected to a PostScript-equipped printer, typed `executive' and created graphics on the fly, you'll have some idea of what it feels like to type `400 500 createcanvas mapcanvas' and have a window appear on-screen. It has all kinds of other powerful features for developers such as light-weight processes in a flat memory space, interprocess message passing, event handling, internationalized font support, input device independence, etc. It'll be interesting to see what kinds of applications are developed for NeWS. A WYSIWIG editor based on it would allow you to paste in any chunk of PostScript from any other application, and could give you interactive access to all the advanced PostScript imaging features (shading, rotation, skewing, clipping, etc.). NeWS won't be out until next year, but it's interesting to ponder the ramifications of a window system environment which makes the distinction between what you get out of the printer and what you see on the screen vanish. ---------- Submissions to: desktop%plaid@sun.com Administrivia to: desktop-request%plaid@sun.com Notes: if you are on the mail.desktop mailing list and see this message, let me know so I can remove you from the direct mailing. Yes, I know this is not a standard digest format. No, I'm not going to change it, since it goes away when the archives are posted. Chuq Von Rospach chuq@sun.COM [I don't read flames] There is no statute of limitations on stupidity