* Pro Forma hasn't had any kind of security review, and so may handle
  unexpected or malicious files very badly.  I've tried to avoid
  glaring errors, but haven't spent a great deal of time looking for
  subtle mistakes.  As a result, I recommend you currently treat Pro
  Forma data files as executable content, and not open any that come
  from somebody you do not trust.  Also, I certainly don't recommend
  installing it setuid or setgid to anything, although I'm not sure
  why you'd want to.  As it stabilizes, I'll go over the code closely
  and try to fix this up.  In the meantime, if you find anything
  dodgy, please let me know and I'll fix it.

* Pro Forma crashes occasionally when resizing textboxes.  Save often,
  and remember this is still very alpha software!

* Pro Forma requires large amounts of memory.  I can't seem to get
  GnomePixbuf to work with any mono bitmap formats, and in order to be
  able to look at the image in the resolution we need, the image has
  to be processed at 300dpi.  That means that for an 8.5x11 page, at
  8bpp, we need at least 6.7 MB of RAM just to store the image.

  In future versions, I hope to be able to support mono bitmap
  formats, which should reduce memory to a little over 1MB.

  I'm hoping this will be fixed by the move to GNOME 2.

* Yes/No/Cancel dialogs don't have a Cancel button.  To cancel, just
  close the window.  There isn't a builtin Yes/No/Cancel dialog in
  Gnome that I could find, and I didn't feel like making one just
  now.  :)

* The output file stores the full path of the base image, and doesn't
  provide a way to change the image if it moves.  To change it, just
  edit the form file with a text editor, and replace the image path
  with the correct path.

* No attempt is made to verify the length of the strings entered into
  textboxes.  It's quite possible to type right off the end of the
  textbox displayed on the screen, and everything you type will be
  displayed.

* Numerous small memory leaks.  When doing things like creating menus
  dynamically, I'm not quite sure how to do memory management
  properly.  I'll figure it out, but in the meantime we should only be
  leaking a few bytes here and there.

* Many errors go to stdout/stderr, instead of being displayed in
  dialogs.

* Debugging code is messy and leaks memory; it is adapted from another
  program of mine, and doesn't 100% fit.

* Dialogs can't be called reentrantly, which could cause problems if
  they are stacked.  Doesn't seem like there are any situations like
  this, but it's not good programming.

* Code is messy, with tons of variables shared between modules with
  random "extern" declarations, and random style changes corresponding
  to code which was generated by Glade, and my mood.

* Glade-generated code is hand-modified, so interface can't be
  automatically regenerated.  :(

* PostScript DSC errors:
  + We don't propogate needed resources up from included EPS files
  + We don't propogate portrait/landscape up
  + We don't handle BoundingBox: (atend) properly.