This file contains some possible things to do in future versions of xfig.

--------------------------------------------------------------------
The following items would require a change to the Fig file protocol:
--------------------------------------------------------------------

Separate dash/dot length from the gap
Allow different arrow head points (miter, round, bevel)
Enhance all objects to have cap_style type for dotted lines
Allow selecting linecap type for dotted lines for closed splines, boxes
	and ellipses
Rotatable boxes - store width, height, upper-left corner and angle only?
Allow multiple pages of figures
Store page size with file
Super/subscripts for text objects
Composite objects (ala PostScript) that can be filled if wanted
	e.g. polyline joined with arc and filled:
	 _______
	(_______)
Text that is connected to objects which appears in popup near object
	e.g. to have extra information about an object, like "this is
	my mother at age 5" in a family tree figure

----------------------------------------------------------
The following DON'T require a change to the file protocol:
----------------------------------------------------------

Libraries of Fig objects to allow drag-and-drop of objects onto the canvas
"Slide show" feature by hitting Alt-N to load next .fig file in the current
	directory.  Also, say Tab in file menu would go to the next file
	in the directory, loading that filename into the Filename slot.
	Credit Alec Muffett (Alec.Muffett@UK.Sun.COM) for the idea.
Option for grid to be constant screen-size (independent of zooming)
Allow define arc by center and two points on radius
Allow picking of points off the positioning grid
Recursively uncompound objects with one click
Show position of mouse in Fig coordinates in new indicator window
Text blocks in text frame
Make CGM export option for fig2dev
Automatic pan of canvas when drawing at an edge.
Make a simple way to create quarter-circle and half-circle using arc
Allow specifing center and two points on radius for arc besides current method
Possibly use already allocated colors when importing GIF/XPM figures
	(e.g. black, red, etc)
Re-render EPS file (using gs) at new resolution when zooming LARGER
Moving object when point_posn mode is on should first move object to closest
	positioning grid position then allow movement from there.
	Cancel should restore original coords.
Confirm Delete All/Save Figure so user doesn't save over old file
  e.g.	1) Work on existing file
	2) save file
	3) delete all to start new figure (filename is old one however)
	4) save new figure should confirm save on old name
Look in ../AppPlusS/XCC.c for code to allocate colors using any
	valid visual/depth/colormap.
When deleting (or adding) an arrowhead the object should be deleted
	from the objects list so the redisplay can be done properly then
	added back in to the list with the arrowhead deleted (or added)
Bug: -pwidth/-pheight values ignored when switching Landscape/Portrait
	This is hard to fix - what if the user wants -pwidth 11 and -pheight 5
	and switches to Portrait mode.  Should the window be made 11 inches tall?
	That is very tall for most displays.
Use already allocated colors when importing GIF/XPM figures (e.g. black, red, etc)
Option for smaller icons for mode panel for smaller screens
Make <Shift>middle mouse button DELETE previous points just created during
	create POLYobject/ARC/Ellipse etc.  That way, one may backup when
	creating objects.
Undo should undo multiple copy, rotate/copy etc.
Should arrow size change in update mode when linewidth changes?
	Easier method to set/change arrow size
Mode to rotate objects using only the mouse (requires new mode button)
Split/join two objects together (e.g. end of one line attached to the beginning
	of another line to make single, new line).  This would only make sense
	for lines/splines?
Make zooming only rescale texts which are visible in the new zoom.  This may be
	a problem because the bounding box of the text at the new size isn't
	known until the font is rescaled.
Make it smart about duplicate GIFs:
	o Same GIFs on canvas use same bitmap[]
	  (each has its own pixmap in case different rotation, size etc)
	o Thus, they all share the same colors
Have "freehand" line drawing mode (draws points as long as mouse button
	is down)
Allow printing of grid in figure (actually fig2dev option)
Make the rulers understand the real screen resolution according to the server
Add the concept of "layers" for each depth.  That way a user may work on
	certain layers at one time, masking out or overlaying the other layers
	as desired.
Create resource for "print" command (e.g. lp, lpr, whatever) which uses meta-
	notation to place filename (e.g.  print_command: "lpr -P%p %f" where %p
	is the printer string and %f is the filename)
Allow option of vertically centering text either using the ascenders/descenders
	(the current method) or not
Allow vertically-aligned text
  "top" would mean the insertion point specifies the line over the top of the
        text
  "middle" would mean that it specifies the midline of the text (I'm not
        sure how this is defined, perhaps the average of top and base
        or top and bottom.
  "base" would mean the line under all letters which do not hang down.
        For example, g and j extend below the baseline.
  "bottom" would mean the time under the bottom of the text including
        descenders.
Have common edit popup for all four splines to allow conversion between all
Save modified_flag before file operations and restore if undo used
Change eps_bitmaps so that background is transparent; i.e. stipple (needs to
	work in normal and reverse-video modes)
Make popup windows come up so that they don't overlap the figure (if possible).
	An edit popup window should at least not overlap the
	object being edited (again only if possible).
Use fill pattern (grey-shading) to mimic color objects on monochrome systems.
Extend smart links to work for SCALE, MOVEPT and perhaps EDIT, UPDATE.
	Could also extend them to work for arc-type links and for
	ellipse/circle objects and objects inside compound objects.
	Also, at the moment smart-links
	only work for one end of a link if both ends of the link
	happen to touch the object being operated on.  To fix this would
	require changing the F_linkinfo structure to have left_endpt,
	left_prevpt, right_endpt, right_prevpt fields instead of the current
	endpt, prevpt and two_pts fields.
Still need to think about how point positioning should be utilized with
	many of the editing commands, e.g. if point positioning is set to
	large grid and you are trying to move an object, should:
	a) it be ignored, b) you can pick up an object anywhere but
	you must put the 'pick-up' point back on a grid posn,
	c) you have to pick up and put down objects at grid posns,
	d) you can pick up and place an object anywhere but when you
	place it, the point on the object closest the pickup point is
	automatically rounded to the nearest grid posn, e) you can
	pick up objects anywhere and movement is multiples of the grid size.
	The current behaviour is c) and b) can be mimicked by changing the
	point posn indicator mid-move.  It has the disadvantage that you
	may not be able to pick up an object which isn't on the grid points.
	I think e) is the next best but it won't let you mimick b).
Use clipping rectangles in more places:
	use the redisplay_* routines as necessary.
Allow popup menus to be pinned?
Make arcs use pw_curve to speed them up.
Add bounding box to every F_object definition, useful for:
	1) faster drawing of rubber objects
	2) handling the selective redrawing of figures better after they become
	   the innocent victim during an expose or erasure of another object
Things like pan/zoom/resize/iconify will still leave junk on the screen
	or mess up the figure if you are in the middle of drawing it:
	One solution is to call canvas_rightbut_proc whenever the
	action_on flag is set and one of the above functions is called.
	This forces the operation being performed to be cancelled - probably
	not a good idea for panning - we might be trying to pan a little
	bit to place the last point in a large object.
	Another solution is to have a big case statement which performs
	a single elastic draw of whatever object is being drawn/moved etc.
	The function would need to be called before an iconify (or
	whatever) and again after the operation was completed.  This
	would allow drawing operations to be continued after window functions
	had been performed.
	A third solution is to use a canvas_elasticdraw_save parameter
	instead of using a case statement - it would need to be set
	prior to every elastic draw operation.
Generalize align mode (like glue mode) to allow arbitrary tagged objects to be
	aligned rather than just compounds.
Some facility to provide better support for small screens.
	e.g. scrollable mode button list or automatic resizing
	to have several rows as needed.  A good test is to limit the total
	space to 640x480 so that it is still useable on an IBM-PC VGA screen.
Make a raise/lower depth feature:
	the raise_ic icon is already in w_icons.c
Make xfig understand depth better:
	If you set the depth using the object edit panels, xfig will redraw
	them correctly, however it would be nice if as you entered new filled
	objects that they were automatically given an appropriate depth.
	This would involve finding the depth of all overlapping (filled?)
	objects and setting the depth to be one less.
	What about support for negative depth values?
Honor fractional text sizes (float).  Currently, xfig reads the size as float
	but converts to integer internally.
Allow direct modification of the tension of a X-spline point from the Edit
	Object window, or at least, allow to copy the tension value from
	one point to another.
In version 3.2, closed X-splines don't have their first point
	duplicated at the end of the list, because a circular list is
	simulated. This technique should also be applied to a polygon object,
	which still duplicates its first point.
A 'gravity' mode whereby points placed by aiming and clicking are brought not
	to the closest fiducial point of a figure, but to the closest continuous
	point on the figure (applies only to circles, arcs, and straight lines),
	taking into account constraints of angle (like manhattan constraint).
	Example 1:  I click near the circumference of a circle.  The point is
	placed exactly on the circumference, closest to where I clicked.
	This is very useful for getting lines to touch circles exactly in points
	other than the E, W, S, or N extreme.  Example 2:  I am in manhattan
	constraint, and I click near a random-slope line.  The point is placed
	on the line in the one place consistent with the manhattan constraint.
Clean up array-place copy:
	If y copies is set to 0, then xfig treats the x direction as the direction
	of the copies.
	If both are non-zero, the x and y are e-w and n-s, but the number of copies
	can be fewer than x*y if the first copy is in a strange place.
	If only y is set, it is like x, but the first copy (when y is 2) is not
	drawn properly.

--------------------------------------------------------------------
--------------------------------------------------------------------
What really needs to be done is a major rework of the list structures used
	to store xfig objects.  Here are some comments involving the change.

-------- note about restructuring xfig data structures -------------
Rather than having a depth attribute for objects, you can use the order
in which objects are entered to determine their depth:  later objects
appear on the top.  A raise/lower depth operation would allow you to
change the ordering.

The consequences to the current implementation of converting totally to this
scheme are non-trivial.  Instead of having separate lists for each object
type, you need to have a single list which has a union of all the different
objects as its type.  This will require changes in many places in the code.
At the moment there are many places where each of the lists are traversed
separately.  In many cases the code can be simplified dramatically if there
was only a single list.  For example, to perform a move on an object there
are separate routines (one for each object type) to start/cancel/place the
object.  You could replace this by a single routine for start/cancel and
place which worked no matter what type you had.  (Who says you can't use
object-orientation in C :-)).  Another advantage is that the current caching
scheme for redrawing would no longer be needed (i.e. redrawing would be
greatly simplified).  Also undo would become simpler (I think).

If we want to make a smooth transition from the current scheme to the
one described above (and I do), here is how I propose we do it:

We need to change every direct access to the current lists to use functions.
i.e. something like
        for (a=objects.arc; a!=NULL; a=a->next) ...
to be something like
        for (a=first_arc(); a!=NULL; a=next_arc(a)) ...

At the moment these routines would be simple to implement.
Once all occurrences had been changed, it would simply be a matter
of changing the underlying list structure and changing the first_arc,
next_arc routines.  Then as we had time we could replace whichever
sets of six loops by a single loop which did
        for (o=first_obj(); o!=NULL; o=next_obj(o)) ...
-------- end of note about restructuring xfig data structures -------------
