Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!ucsd!ucsdhub!hp-sdd!hplabs!hpda!hpcupt1!hpcuhb!hpesoc1!cunniff
From: cunniff@hpesoc1.HP.COM (Ross Cunniff)
Newsgroups: comp.sys.amiga.tech
Subject: Re: A modest proposal (was IFF/Quickdraw)
Message-ID: <10630006@hpesoc1.HP.COM>
Date: 19 May 88 18:31:03 GMT
References: <4083@gryphon.CTS.COM>
Organization: Hewlett Packard, Cupertino
Lines: 70

In article <4083@gryphon.CTS.COM>, richard@gryphon.CTS.COM (Richard Sexton)
writes:
>For inclusion into IFF files, I propose that types (or hunks or whatever
>the appropos terminology is) be invented that correspond directly to
>PS primitives. What we end up with then, is essentially Amiga quickdraw,
>except we dont call it quickdraw.

OK!  Now we're talking.  A quick perusal of the PostScript Language Reference
Manual reveals the following primitives:

	arc	arcn	arcto	curveto	lineto	moveto	rcurveto
	rlineto	rmoveto	show

How these are displayed may be modified by the following primitives:

(path primitives)
	newpath		closepath	flattenpath	reversepath
	strokepath	charpath	clippath	pathforall
	clip		fill		eofill		stroke

(style primitives)
	setlinewidth	setlinecap	setlinejoin	setmiterlimit
	setdash		setflat		setgray		sethsbcolor
	setrgbcolor

(transformation primitives)
	initmatrix	setmatrix	translate	scale
	rotate		concat

A filled polygon would then be represented as:

	1.0 1.0 0.0 setrgbcolor		% Set the fill color to yellow
	0 0 moveto
	5 5 lineto
	0 5 lineto
	5 0 lineto
	gsave fill grestore		% Fill, saving the path for later
	1.0 0.0 0.0 setrgbcolor		% Set the edge color to red
	[3 1 1 1] 0 setdash		% Set '._._.' lines
	stroke				% Trace the edge



The equivalent DR2D object would be:

	CPLY [F_COLOR 3 E_DOT_DASH 2] 8   0 0  5 5  0 5  5 0

We can define equivalent DR2D objects for the rest of PostScript's
primitives.  I propose, however, that we don't use the full power
of PostScript's clipping and imaging model, just because it is
*SUCH* a pain to implement (especially for vector-only displays, such
as plotters), and is far too general for a drawing format.
I think that we should limit ourselves to fairly straightforward
transformations and clips (i.e. clipping to a rectangular window and
only allowing translation, rotation, and scaling as transformations;
we shouldn't bother with text along arbitrary curves, that sort of stuff).

Also, for you PostScript purists out there, looking at the above, which
do YOU think would be easier to parse and group into appropriate objects
for manipulation by the user?  Remember, we are trying to design a format
for CAD-type programs that the user will be able to modify after she's
saved it.  High-level objects are a much easier paradigm to handle than
a series of interpreted move/draw/fill type commands (oh, sure, you
could say, 'Well, we would just write a PS procedure for each high-level
object type'.  Fine.  Now we need the full-blown interpreter.  No thanks).


					Ross Cunniff
					...{ucbvax,hplabs}!hpda!cunniff
					cunniff%hpda@hplabs.ARPA