TO DO and Changes to make to CirclePack:

-- Want way to find out what vertex is currently centered at origin.

-- shading_err.cmd shows annoying problem with shading of discs on
   the sphere

-- When trying to specify a redchain with "fix -f <f..>", there is a
   problem with blue faces -- they can get left out. This results from
   my approach: I use the putative red chain to identify "poison"
   verts. Then the blue faces can get passed by as the new red chain
   is generated.

-- "print" causes segmentation. The "post_fp" file pointer is not 
   being opened.

-- Need "edge picking" capability (at least for euclidean). Put
   screen in correct mode, then pick edges with the mouse.

-- Need to check out the "mend" routines.

-- Need way to keep centers unchanged but apply mobius maps for
   desired screen display -- probably not something for CirclePack,
   but rather for standalone routines. However, might store the
   current Mobius in file and, when it's there on read, apply it
   before displaying.

-- Check that display option flags are updated to repeat last display

-- Can we get Vlist call, if empty, to default to none rather than all
   circles?

-- Way to plot in order, but only display the circles around a designated vert
   as it's layed out.

-- Need routine to pin down where layout errors are started.

-- Should be able to cut out, repack, and blend back in a section of
   a packing to fix locallized flaws. Need functionality for following
   curves overlaying a circle packing.

-- Need to build chains of circles/faces lying along a curve because:
   * want to draw them, make list
   * want to cut out, repack, blend back in partions of a packing
     surrounded by a curve
   * want to build piecewise linear map between circle packings
     so need efficient way to find faces line passes through.


-- Might arrange in layout order to bypass 4 degree (and 5 degree?) vertices
   and put them im later. Might also (after talking with Chuck) go back
   after star of vert is completed and jiggle it to distribute any
   plotting errors.

-- Triangle color doesn't get written. eg. with -M 

-- may need to "molify" triangles to smooth placement.

-- add "color" to info reported on faces/circles

-- erroneous "blend usage" message with ?vert call.

-- calling ?vert with index exceeding nodecount defaults to
   some vert number. Why?

- internally might use fread/fwrite calls to store stuff
  in binary form -- eg. with temporary p_light data.

- Reorganize color routines: make _call routine which is easier to
  maintain, default to circles without -f flag, color by angle sum
  over/under, copy color should use vertex_map if available.
  Other coding: compare p1 p2, but put colors, eg, in p0. Color
  files reflecting "activity" in packing computation, eg, number
  of increases, decreases.

- build a Java interface to run Repack in various ways. Use it
  as a training device to develop automated methods for a 
  program executive to parcel out the repacking tasks in a
  parallel implementation.

- Consider using "flood" technology for getting red chain for
  other tasks. E.g. in original processing of data, to help handle
  "walls", disconnected pieces, non local-planarity, etc.

- maybe hyp circle labels should be at eucl center?

- develop formula for hyp center of triangle, put labels there.

- put colors and labels in post_any_face, check draw_any_face, etc.

- incorporate some high-precision routines using pari libraries,
  called when you want extra precision. E.g., perhaps Mobius
  transforms should always be computed this way. Should have
  repack routine, slow but accurate.

- with flags, might get rid of redundant routines, e.g., drawing
  circle/face numbers.

- put multiply-connected demo in demo.cmd chain.

- do you save any cycles in C by using, eg, 'redlist' for 'p->redlist'??
  I think not, but might save by only sending to subroutine those
  parts of p needed.

- what does fix -l do in non-simply connected case?

- Should redfaces be discarded for simply connected complexes
  (unless, eg., there is a drawlist)?

- check "slit" and allow it to cut from bdry to bdry

- need combinatorial routines for:
  short path from v to w
  n-generation subcomplex from v (with holes filled in)
	       (May be able to do this by setting red chain
	       type growth and, to catch holes, observing
	       when it first touches itself.

- Dual graph construction?

- parens programmed in edge_list_parse. (e.g. along a bdry or
  red chain segment, along shortest path between, etc. )

- check what happens to new redfaces info under hex_refine?

- methods to improve quality of red chain: e.g., eliminate
  edge-paired blue faces? When red chain first hits self,
  try to balance added faces on the opposite sides? Go back
  in and move the red chain? E.g., make adjustments in
  fundamental domain -- perhaps clicking and moving individual
  faces?

- "protected vertex" list to facedraworder as alternative to
  "drawlist". (Will take some more thought and planning.)

- no longer need to prune faces without interior ngbh's, e.g.
  in cookie.

- circles on sphere are "backward" compared to flat map -- math is
  correct, but not consistent with normal thinking. Maybe put option
  in .packrc

- should have button to bring up canvas "deiconify" it if it's an icon.

- fix reading command in DesPack; maybe use "select" process

- Translation stuff:
  - read in, set flag
  - else, reset table on read.
  - table will be corrupted on some comb changes. Flush?
  - write out in M write mode

- "pair_picking" routine can be problem if vertices for string
  of edges are not in correct order.

- where do colors of horocycles come from?

- what's diff between -e and -e a?

- Hook in *.html scripts

=============================

- if inv_distances always fall in certain patterns, might be able
  to improve recompute time by specialized routines, e.g. models
  like Chuck's "uniform" neighbor.

- might try lookup tables for speeding some computations

- In live action settings, might be able to give preliminary results as
  computations are proceeding: e.g., repack large but local nbhd and
  display while real computations continue in background. Similarly for
  refinements -- could go ahead and compute local bit while rest is
  being packed.

- 'get_data -v' should transfer vertex_map.

- should all vertex_map stuff be in map?

- need Vertex_map utility string.

- need to madify translation procedures to allow more general
  vertex_maps. Complication: to check index size, need to pass
  nodecount or something.

- write utility "cmd_line_parse" which takes a datastr and picks
off the "-" indicated flags and the remaining free-form string and
puts them in locations for use by the calling routine. (Are "-p1"
and "-q0" examples of the only commands with more than one character
after the '-'?)

- need more checks to stop arithmetic errors when computing centers
  with poor radii

- fix up the bdry_comp pointers so we can allocate space only as needed.

- make 'molify_cent' as the standard way to lay out a packing; however,
  have to adjust the method in multiply-connected cases for verts on
  outside of red chain. Probably need to keep plot info in red chain
  data structure so when plotting a given vert we know which neighbors 
  have been plotted in spots we should use.

- put flag with geom_to_h which does a straight transition of (legal)
  radii and centers, without globally checking for largest, etc. to
  maintain a packing.

- figure out way to organize data so one can swap out flowers; that
is, if you want to work with some subcomplex, instead of creating a
new packing, you just temporarily redefine the flowers (and .num)
data so the repacking routine just computes the data you want.

- Might consider building in a "vertex order" for layout rather
than a face order (at least in simply connected cases). With locations
being molified anyway, it's not so important which face is being
drawn; the next circle uses all possible pairs of neighbors.

- Might consider repacking computation in order of circle layout
instead of simple numerical order. Than way might get the ones
that are most crucial to layout done first.

  For example: for hyp packing, might add ideal vert, puncture at
alpha, make new ideal vert V the temporary alpha, do the packing around
this new alpha, then do "cir_invert -u V" to put the original packing
(less the punctured vert) into the disc. Using drawing order for repack
makes sense because you might work only on the verts in the early
generations, get them to lay out before moving on to those deeper
in the final packing.