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