🚀 go-pugleaf

#!/bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #!/bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
#	wind14.prf
#	tut.prf
#	macros.prf
# This archive created: Fri Jun 27 02:53:58 1986
# By:	Jwahar R. Bammi ()
export PATH; PATH=/bin:$PATH
echo shar: extracting "'wind14.prf'" '(22068 characters)'
if test -f 'wind14.prf'
then
	echo shar: over-writing existing file "'wind14.prf'"
fi
sed 's/^X//' << \SHAR_EOF > 'wind14.prf'
X.!****************************************************************************
X.! 
X.! ANTIC PUBLISHING INC., COPYRIGHT 1985.  REPRINTED BY PERMISSION.
X.!
X.! ** Professional GEM ** by Tim Oren
X.!
X.! Proff File by ST enthusiasts at
X.! Case Western Reserve University
X.! Cleveland, Ohio
X.! uucp : decvax!cwruecmp!bammi
X.! csnet: bammi@case
X.! arpa : bammi%case@csnet-relay
X.! compuserve: 71515,155
X.!
X.!****************************************************************************
X.!
X.!
X.!****************************************************************************
X.!
X.!			Begin Part XIV
X.!
X.!****************************************************************************
X.!
X.PART XIV USER INTERFACES - Part 2
X.PP
XThis  issue of ST PRO GEM (#14) continues the  discussion  of
Xuser  interface  design which began in episode eight.   It  begins
Xwhere  we left off,  with a further treatment of the mode problem,
Xand  proceeds  into  topics such as visual  grammar  and  layered
Xinterfaces.
X.PP
X     Note  that  there  is  no  download  for  this  column.   The
Xdownloads  will return with the next issue,  a discussion of using
Xthe  GEM DOS file system within a GEM application.   Specifically,
Xit  will include sample code for using the file selector,  the GEM
Xform_error  alerts,  and some utilities for manipulating file  and
Xpath names.  There will also be a feedback section.  The following
Xtwo columns will be devoted to "graphics potpourri",  a collection
Xof  small  but useful GEM utilities such as  popup  menus,  string
Xediting, and source code for drag and rubber box operations.
X.SH MODES AGAIN
XIf a program is modeless, it acts predictably,
Xwhich turns out to be very important.   On the other hand,  a good
Xdefinition  for  "modes"  is hard to find.   In  column  eight,  I
Xsuggested  that  a  mode exists when you cannot  use  all  of  the
Xcapabilities  of the program without performing some  intermediate
Xstep.   If  this  is  less  than clear,  here  are  two  alternate
Xdefinitions offering different views of the problem.
X.SH THE "TWO USER TEST"
XConsider  the  following  thought
Xexperiment:   Imagine  that  your ST (and GEM) had two  mice,  two
Xcursors,  and  two  users.   Could  they both effectively use  the
Xprogram at the same time?  If so, the application is modeless.  If
Xthere are points where one user can be "locked out" by the actions
Xof  the other,  then a mode exists at that point.  Let's  consider
Xsome examples of this test.
X.PP
XIn any program which uses the GEM menu system, one user could
Xstop  the  other by touching a menu hotspot and dropping  a  menu.
XThis constitutes an inherent mode in the GEM architecture.
X.PP
XOn  the  GEM Desktop,  two users could open windows and  view
Xfiles without interference.   However, as soon as one person tries
Xto delete a file (assuming the verify option is on),  the other is
Xbrought  to  a halt as a dialog appears.   Thus,  we have found  a
Xmodal dialog.
X.PP
XIn  many "Paint-type" programs,  such as MacPaint,  PC Paint,
Xand  GEM Paint,  two artists could co-exist quite well,  utilizing
Xthe  on-screen  palette  and tool  selection.   Of  course,  these
Xprograms  also contain modal dialogs for such operations  as  file
Xand  brush  shape  selection.   In contrast,  consider  the  paint
Xprogram  DEGAS  for  the ST.   Here,  two artists could only  work
Xtogether as long as neither wanted to change tool or color.   Then
Xthe  display  would have to be flipped to  the  selection  screen,
Xstopping the other user.  This is a mode in the DEGAS interface.
X.PP
X(By the way, this test is not just academic.  The grand-daddy
Xof all mouse based systems, NLS, demonstrated by Doug Englebart in
X1968,  had  two  mice  and two users,  one of whom was  physically
Xremote.   Cooperative  techniques  such as this are still  largely
Xunexplored and unexploited.)
X.SH ONE LINER
XHere's  a  terse definition by  Jef  Raskin:  A
Xprogram is modeless if a given action has one and only one result.
XAgain, let's run a few examples.
X.PP
XThe  menu  dropdowns are clearly modal  by  this  definition.
XBefore  the  menu was activated,  window control points  could  be
Xactivated with a click.   However, when the dropdown is visible, a
Xclick action is interpreted as a menu selection or a dismissal  of
Xthe dropdown.   Similarly, dialogs are modal because the action of
Xmoving  the mouse into the menu bar no longer causes the  dropdown
Xto appear.
X.PP
XI am typing this using the First Word editor program.  It has
Xa  nice desktop level box full of characters where I can click  to
Xget  symbols which the ST keyboard won't produce.   However,  if I
Xinvoke  the  find or replace string dialog,  the  click-in-the-box
Xaction  doesn't  work anymore.   This is a mode in the First  Word
Xinterface.
X.PP
XFinally, consider an "old style" menu program, the kind where
Xyou  type in the number of the desired action from a list.   Since
Xthe  number  "2" might mean "Insert the record" in one  menu,  and
X"Purge  the file" in another,  such a program is clearly modal  by
XRaskin's definition.
X.PP
XThese  three definitions say almost the same thing,  but from
Xdifferent  viewpoints.   Depending  on the situation,  one or  the
Xother  may  be more intuitive for you.   The goal of this type  of
Xanalysis  is to root out unnecessary modes,  and to make sure that
Xthose  which remain only appear when requested by the user,  offer
Xsome visual cue such as a rubber line or standard dialog box,  and
Xare used consistently throughout the application.
X.SH PREDICTABILITY FOREVER AND EVER AND EVER
XAs  Raskin's
Xdefinition  makes  clear,  when the modes go away,  the  interface
Xbecomes  predictable.   Predictability  leads to the formation  of
Xhabits   of   use.     Habits  reduce  "think  time"  and   become
Xprogressively faster due to the Power Law of Practice discussed in
Xcolumn eight.  This is exactly what we want!
X.PP
XThere is another benefit of predictability.   A habit learned
Xin  one  part  of a program with a  consistent  interface  can  be
Xtransferred  and  used elsewhere in the application.   If  several
Xprograms share the same style of interface, the same habits can be
Xused across a complete set of products.  Learning time for the new
Xfunctions becomes shorter,  and the user is more likely to use the
Xnew feature.
X.SH IS A BOGEYMAN!
XMost  casual  users are  scared  silly  of
Xcomputers  and programs.   (If you have any doubt,  eavesdrop on a
Xsecretary with a new word processor,  or the doctor's receptionist
Xcoping with an insurance data entry program.)  In most cases, they
Xhave  a  right to be frightened.   Even  experienced  programmers,
Xprone  to  toss  the manuals and hack  away,  know  that  moderate
Xparanoia  is  the best way to deal with an unknown  program.   How
Xmust this feel to someone whose ability to perform (or lose) their
Xjob depends on an unpredictable (aha!) black box.
X.PP
XSo here's another way in which predictability works.   But to
Xproduce  a truly fearless user,  we need other qualities as  well.
XOne  is robustness,  meaning that the program will not crash given
Xnormal or even bizarre actions by the user.   Another is feedback,
Xwhich shuts off invalid options,  reinforces correct actions,  and
Xgives  reassurance  that  an  operation  is  proceeding  normally.
XFinally, we need forgiveness, in the form of inverse operations or
XUndo options, when the inevitable mistake is made.
X.PP
XThe  ultimate  goal is make the program  discoverable.   This
Xmeans  the user should be able to safely "wing it" after  a  short
Xsession  with  the application and its interface.   This  practice
Xought to be considered the norm anyway, since the manual is always
Xacross  the office or missing when an esoteric and  half-forgotten
Xfeature  is  needed.   If it is possible to muddle through such  a
Xsituation  by  trial  and  error,   without  causing  damage,  the
Ximmediate  problem  will  be  solved,   and  the  user  will  gain
Xconfidence.
X.SH GOOD GRAMMAR OR...
XSo exactly what are these habits that are
Xsupposed  to be so helpful?   One of the most useful patterns is a
Xconsistent  command  grammar  for the  program.   This  may  sound
Xstrange,   since   we  have  supposedly  abandoned  command   line
Xinterfaces  in the graphics world,  but in fact,  the same type of
Xrules apply.   For instance, in the world of A> we might issue the
Xcommand:
X.br
X.sp
X.ce
Xcopy a:foobar.txt b:
X.PP
XBy  analogy  to  Englist grammar,  this command contains  a  verb,
X"copy",  a  file  as  subject:  "a:foobar.txt",  and a location as
Xan object: "b:".  The equivalent GEM Desktop operation is:
X.BO
X- Move mouse to foobar.txt icon in a: window
X.EO
X.BO
X- Press mouse button
X.EO
X.BO
X- Move mouse to b: icon
X.EO
X.BO
X- Release mouse button
X.EO
X.PP
XThe  operation  can be described as a  select-drag-drop  sequence,
Xwith  the select designating the subject file,  the drag  denoting
Xthe  operation  (copy),  and the location of the drop showing  the
Xobject.   A  grammar still exists,  but its "terminal symbols" are
Xcomposed  of  mouse  actions interpreted in  the  context  of  the
Xcurrent screen display, rather than typed characters.
X.PP
XOne  useful way to analyze simple grammars,  including  those
Xused  as  command  languages,  is to separate  them  into  prefix,
Xpostfix,  and infix forms.   In a prefix grammer, the operation to
Xbe  performed precedes its operands,  that is,  its subject(s) and
Xobject(s).   The  DOS copy command given above is an example of  a
Xprefix  command.   LISP  is  an example of a language  which  uses
Xprefix specification for its commands.
X.PP
XPostfix grammars specify the action after all of the operands
Xhave been given.   This command pattern is familiar to many as the
Xway  in  which  Hewlett-Packard calculators  work.   FORTH  is  an
Xexample of a language which uses a postfix grammar.
X.PP
XInfix  notation  places the verb,  or operator,  between  its
Xsubject and object.   Conventional algebraic notation is infix, as
Xare most computer languages such as C or PASCAL.   The example GEM
Xcommand  given  above  is also infix,  since the  selection  of  a
Xsubject  file  preceded  the action,  which was  followed  by  the
Xdesignation of an object.
X.PP
XThe  "standard" GEM command grammar,  as used in the products
Xproduced  by Digital Research,  is in fact infix.   This is not to
Xsay that GEM enforces such a convention,  or that it is rigorously
Xfollowed.  However, when there is no pressing reason for a change,
Xadoption  of an infix command grammar will make  your  application
Xfeel most like others which users may have seen.
X.PP
XThe general problem of specifying a graphic command  language
Xcan be difficult, but much of the problem has already been handled
Xon the ST.   Part of the solution is by constraint:  the input and
Xoutput hardware of the ST are predefined,  so most developers will
Xnot  need  to  worry about choosing a pointing  device  or  screen
Xresolution.   The  other part of the standard solution is the  GEM
Xconvention for mouse usage.  I am going to review these rules, and
Xthen describe of the situations in which they have been bent,  and
Xfinally  some alternate approaches which may prove useful to  some
Xdevelopers.
X.SH SPECIFYING A SUBJECT
XThere are really two sets of methods
Xfor  designating what is to be affected by an operation.   One set
Xis  used when distinct objects are to be affected.   Examples  are
Xfile and disk icons in the Desktop and trees in the RCS.   Another
Xset of designation methods is used when continuous material,  such
Xas text or bit images, is being handled.
X.PP
XWhen dealing with objects, a single mouse click (down and up)
Xover the object selects it.   The application should show that the
Xselection  has occurred by changing the appearance of the  object.
XThe  most  common  methods are inverting the  object,  or  drawing
X"handles" around it.
X.PP
XMany   operations   allow  "plural",   or  multiple   object,
Xselections.  The GEM convention is that a click on an object while
Xthe  shift key is held down extends the selection by  adding  that
Xobject.   If the shift-clicked object was already selected,  it is
Xdeleted from the selection list.
X.PP
XAnother  way to select multiple objects is to use  a  "rubber
Xbox"  to enclose them.   This operation begins with drag on a part
Xof  the  view where no object is present.   The  application  then
Xanimates a rubber box on the screen as long as the mouse button is
Xheld  down.   When the button is released,  all objects within the
Xcurrent extent of the box are selected.   A shift-drag combination
Xcould be used to add the objects to an existing selection list.
X.PP
XSelecting  part of a text or bit plane display is  also  done
Xwith a rubber box.   Since there are no "objects" in the view, any
Xmouse  drag  is  interpreted  as  the  beginning  of  a  selection
Xoperation.   In  the  simplest  case,  a bit plane,  the rectangle
Xwithin the box when the button is released is the selected extent.
X.PP
XWhen  the  underlying data has structure,  such as words  and
Xlines  of  text,  the display should reflect this fact during  the
Xselection  operation.   Typically,  text selection is indicated by
Xinversion  of  the  characters  rather than  a  rubber  box.   The
Xselection  extends  along the starting line so long as  the  mouse
Xstays  within the line.   If the mouse move off the starting  text
Xline, the implied selection is all characters between the starting
Xcharacter  and the character currently under the mouse,  which  is
Xnot necessarily a rectangular area.
X.PP
XAn  extended  "plural"  selection may be  supported  in  text
Xediting.   The  use of the shift key is also conventional in  this
Xapplication.
X.SH ACTION
XWith the subject designated, the user can now choose
Xan operation.   In many cases,  this will be picked from the menu,
Xin  which  case  the  entire  command  is  complete.    Some  menu
Xselections will lead to dialogs,  in which the interaction methods
Xare  regulated  by  the GEM form manager.   When  the  command  is
Xcompleted,  it  is  often  helpful if the application  leaves  the
Xobjects  (or areas) selected and ready for another  operation.   A
Xsingle click away from any object is interpreted as cancelling the
Xselections.
X.PP
XMany  operations  are indicated by gestures  on  the  screen.
XUsually,   this  is  some  variant  of  a  drag  operation.    The
Xinterpretation of the gesture may depend on the type and  location
Xof the selected subject,  which part of it is under the mouse, and
Xin what location the drag terminates.
X.PP
X"Handles"  are small boxes or dot displayed around an  object
Xwhen it is selected.   A drag beginning with the mouse on a handle
Xis  usually  interpreted  as  a resizing  operation,  if  this  is
Xappropriate.   The  pointing  finger  mouse form is  displayed  to
Xindicate  the operation in progress,  and a rubber version of  the
Xobject  is animated on the screen to show the user the  result  if
Xthe  button  were released.   In some cases,  where an  underlying
X"snap"  grid  exists,  the  animated  object may  change  size  in
Xdiscrete steps.
X.PP
XDragging  a non-handle area of a selected object  is  usually
Xinterpreted  as  the  beginning  of  a  move  function.   In  most
Xapplications,  a  move  of a single object may be started  without
Xpre-selection.   Simply  beginning the drag on the object is taken
Xto imply selection.  The spread hand, or "grabber", mouse form  is
Xtypically displayed during a drag operation.
X.PP
XDragging  may  denote copying or movement,  or  more  complex
Xfunctions such as instantiation or generalization.   The operation
Ximplied by movement on the screen will differ among  applications,
Xand  often  within  the  same  application,  depending  on  target
Xlocation.   This  target is the recipient of the command's action,
Xor its object, in an English grammar sense.
X.PP
XFor  example,  a  drag from window to window in  the  Desktop
Xdenotes a copy.   On the other hand, dragging the same icon to the
Xtrashcan  deletes it completely.   Dragging an object from the RCS
Xpartbox  to the editing view creates a new copy of that  prototype
Xobject.   Dragging  the  same object within the edit  view  simply
Xchanges its placement.
X.PP
XThere   are  some  mouse  actions  which   are   conventional
X"abbreviations".   A  double click on an object is interpreted  as
Xboth a selection and an action.   Usually, the double click action
Xis the same as the Open entry in the "File" menu.
X.PP
XWhen  the  usual interpretation of a drag is  movement,  then
Xshift-drag  may be used as an enhanced varient  implying  copying.
XFor  instance,  shift-dragging  an object within the  RCS  editing
Xwindow  makes  a  copy of the object and places it  in  the  final
Xlocation.
X.PP
XTo return to the beginning of this discussion, the reason for
Xadopting  these conventional usages is to build an interface  that
Xpromotes  habits.   Particularly,  a  standard grammar for  giving
Xcommands helps answer the question "What comes next?".   It breaks
Xthe user's actions into logical phrases,  or chunks,  which may be
Xthought of a whole, rather than one action at a time.
X.SH DIFFERENT FOLKS, DIFFERENT STROKES
X.PP
XThere  are  always
Xexceptions to a rule,  or so it seems.   In this case, consistency
Xof   the  interface  grammar  is  sometimes  traded  off   against
Xconsistency of metaphor,  preservation of screen space,  and "fast
Xpath" methods for experts.
X.PP
XOne example is the use of "tools" in Paint and Draw programs.
XIn  such  programs,  an  initial  click is made on  a  tool  icon,
Xdenoting the operation to be applied to all following  selections.
XThis is an prefix style of grammar,  and stands in contrast to the
Xusual  method  of selecting subject object(s) first.   Because  of
Xthis contrast,  it is sometimes called "moding the cursor".   (Try
Xapplying the tests above to be sure it really is a mode.)
X.PP
XIn  these  cases,  there  are two reasons for  accepting  the
Xnonstandard  method.   The first is consistency of metaphor.   The
X"user model" portrayed in the programs is an artist's work  table,
Xwith  tools,  palette,  and  so  on.   The cursor moding action is
Xequivalent  to  picking up a working tool.   The second reason  is
Xspeed.   In a Paint program,  the "canvas" is often modified,  and
Xspeed  in  creating or changing the bits is  important.   In  more
Xobject  oriented applications such as Desktop or RCS,  the objects
Xare more persistent.   Speed is then more essential when adding or
Xchanging properties of the objects.
X.PP
XWhen  command  styles  are mixed in this  fashion,  you  must
Xdesign very carefully to avoid conflicts or apparent  side-effects
Xin  the  command language.   For example,  in GEM Draw picking  an
Xaction from the Edit menu cancels the current cursor mode  without
Xwarning.   Confusion  from  such side-effects may cancel  out  the
Xbenefits of the mixed grammar.
X.PP
XThe  subject  of command speed  deserves  further  attention.
XWhile  the  novice approaching a program needs  full  feedback,  a
Xperson who uses it day in and day out will learn the program,  and
Xwant  faster  ways  to get the job done,  even if  they  are  more
Xarcane.  The gives rise to a "layered" style of interface.
X.PP
XA layered interface is designed so that the visual grammar is
Xobvious,  as  we  have discussed.   However, there are one or more
Xsets of "accelerators" built into the program, which may be harder
Xto find but faster to use.  One example is condensed mouse actions
Xsuch  as the double-click.   For instance,  attempting to select a
Xblock  of text which extends beyond a window is  impossible  using
Xthe  basic metaphor.   The novice will simply do the operation  in
Xpieces.   A  layered interface might put a less obvious Mark Begin
Xand  Mark End option in the menus.   Another way is to take a drag
Xwhich  extends outside the window as a request to begin  scrolling
Xin that direction, while extending the current selection.
X.PP
XOne  of  the most common and useful  accelerator  methods  is
Xfunction  keys.   Using  this approach,  single key equivalents to
Xactions are listed in the menu.   Striking this key when an object
Xis  selected  will cause the action to occur.   Note that this  is
Xmost  useful if some keyboard driven method of  object  selection,
Xsuch as tabbing, is also available.  Otherwise, the time switching
Xfrom  the  mouse,  used to select the object,  to the keyboard for
Xcommand input, may well cancel any advantage.
X.PP
XFinally,  radical  departures  from the GEM metaphor  may  be
Xuseful when attempting to replicate the look of another system, or
Xtrying  to  meet severe constraints,  such as display space.   One
Xexample  would  be discarding the standard GEM menus in  favor  of
X"popup"  menus which appear next to the current mouse position  in
Xresponse  to  a click on the second button.   This method has  the
Xadvantage  of preserving the menu space at the top of the  screen,
Xand  is potentially faster because the menu appears right next  to
Xthe  current mouse position.   The drawbacks are lack of a  visual
Xcue for naive users trying to find the commands,  and the need for
Xcustom coding to build the popups.
X.SH MORE TO COME
XWe have reached the end of the second sermon
Xon  user  interface.   In a future column,  I will look at "higher
Xlevel"  topics  relating to the design of the  application's  user
Xmetaphor.   These  include  issues of object  orientation,  direct
Xmanipulation,   and  the  construction  of  microworlds.   In  the
Xmeantime,  several  of  the  more practical columns  will  present
Ximplementions  of  techniques such as accelarator keys  and  popup
Xmenus which I have discussed this time.
X.PP
XTHANKS AND APOLOGIES to the following people whose public and
Xpublished   remarks  have  formed  part  of  the  basis  of   this
Xdiscussion:  Jef Raskin, Bill Buxton, Adele Goldberg, James Foley,
Xand Ben Schneidermann.  As always, any errors are my own.
X.!
X.!
X.!*****************************************************************************
X.!*									      *
X.!*				End Part XIV				      *
X.!*									      *
X.!*****************************************************************************
SHAR_EOF
if test 22068 -ne "`wc -c 'wind14.prf'`"
then
	echo shar: error transmitting "'wind14.prf'" '(should have been 22068 characters)'
fi
echo shar: extracting "'tut.prf'" '(1236 characters)'
if test -f 'tut.prf'
then
	echo shar: over-writing existing file "'tut.prf'"
fi
sed 's/^X//' << \SHAR_EOF > 'tut.prf'
X.!****************************************************************************
X.! 
X.! ANTIC PUBLISHING INC., COPYRIGHT 1985.  REPRINTED BY PERMISSION.
X.!
X.! ** Professional GEM ** by Tim Oren
X.!
X.! Proff File by ST enthusiasts at
X.! Case Western Reserve University
X.! Cleveland, Ohio
X.! uucp : decvax!cwruecmp!bammi
X.! csnet: bammi@case
X.! arpa : bammi%case@csnet-relay
X.! compuserve: 71515,155
X.!
X.!****************************************************************************
X.!
X.!			Begin Tutorial
X.!
X.!***************************************************************************
X.!
X.!
X.so macros.prf
X.so wind1.prf
X.so wind2.prf
X.so wind3.prf
X.so wind4.prf
X.so wind5.prf
X.so wind6.prf
X.so wind7.prf
X.so wind8.prf
X.so wind10.prf
X.so wind11.prf
X.so wind12.prf
X.so wind13.prf
X.so wind14.prf
X.!
X.! Add any further Parts Above
X.!
X.cl 0 APPENDICES
X.so apndx1.prf
X.so apndx2.prf
X.so apndx3.prf
X.so apndx4.prf
X.so apndx5.prf
X.so apndx6.prf
X.so apndx7.prf
X.so apndx8.prf
X.so apndx9.prf
X.so apndx10.prf
X.!
X.! Add any further Appendicies Above
X.!
X.so toc.prf
X.!
X.!
X.!****************************************************************************
X.!
X.!			End Tutorial
X.!
X.!***************************************************************************
SHAR_EOF
if test 1236 -ne "`wc -c 'tut.prf'`"
then
	echo shar: error transmitting "'tut.prf'" '(should have been 1236 characters)'
fi
echo shar: extracting "'macros.prf'" '(1170 characters)'
if test -f 'macros.prf'
then
	echo shar: over-writing existing file "'macros.prf'"
fi
sed 's/^X//' << \SHAR_EOF > 'macros.prf'
X.!****************************************************************************
X.!
X.!				Macros
X.!
X.!****************************************************************************
X.!
X.! Begin New Part
X.!
X.define PART
X.he /Professional GEM//#/
X.bp
X.bold on
X.ce 1
XPART - $1
X.br
X.sp 1
X.ce 1
X$2 $3 $4 $5 $6 $7 $8 $9
X.bold off
X.cl 0 PART - $1.  $2 $3 $4 $5 $6 $7 $8 $9
X.he /Professional GEM/Part $1/#/
X.sp 1
X.en
X.!
X.! Section Heading
X.!
X.define SH
X.cl 1 $1 $2 $3 $4 $5 $6 $7 $8 $9
X.ne 5
X.sp 2
X.bold 1
X$1 $2 $3 $4 $5 $6 $7 $8 $9
X.br
X.sp 1
X.ti +5
X.en
X.!
X.! Figure Begin
X.!
X.define FB
X.ne 3
X.br
X.cl 2 $1
X.sp 1
X.ce on
X.en
X.!
X.! Figure End
X.!
X.define FE
X.br
X.ce off
X.sp 1
X.en
X.!
X.! Paragraph
X.!
X.define PP
X.ne 3
X.sp 1
X.ti +5
X.en
X.!
X.! Begin Option
X.!
X.define BO
X.sp 1
X.in +4
X.en
X.!
X.! End Option
X.define EO
X.in -4
X.en
X.!
X.!
X.define AP
X.fi
X.he /Professional GEM/Appendix $1/#/
X.bp
X.cl 1 Appendix - $1 $2 $3 $4 $5 $6
X.ce on
X.bold on
XAppendix - $1
X.br
X$2 $3 $4 $5 $6
X.bold off
X.ce off
X.sp 3
X.nf
X.en
X.!
X.!
X.!****************************************************************************
X.!
X.!				End Macros
X.!
X.!****************************************************************************
SHAR_EOF
if test 1170 -ne "`wc -c 'macros.prf'`"
then
	echo shar: error transmitting "'macros.prf'" '(should have been 1170 characters)'
fi
#	End of shell archive
exit 0
-- 
					Jwahar R. Bammi
			       Usenet:  .....!decvax!cwruecmp!bammi
			        CSnet:  bammi@case
				 Arpa:  bammi%case@csnet-relay
			   CompuServe:  71515,155