[ePiX-devel] Current status of ePiX-1 and 2

[epix-devel]

The implementation of ePiX-1.0.23 will differ substantially from
1.0.22. The user interface as documented in the manual will not
change, but internal functions formerly exposed in header files will
either be removed or relocated. The changes have two primary goals:

(i) To make the code easier to understand, maintain, and extend,
(ii) To fix some annoying, if unusual, bugs caused by bad design.

As a fringe benefit, new capabilities will be introduced, such as page
markup. The design follows that of ePiX-2 to a large extent. Here are
the main changes I currently foresee:

1. There will be a picture class, comprising
  - True and virtual dimensions
  - Current contents (labels, paths, and polygons)
  - A style (the present "epix" class), governing the picture's
    "current drawing state" (line style/color, font, filling, etc.)
  - A camera

  A picture can
  - Crop itself against a variety of masks
  - Import other pictures (insets, page markup)
  - Write itself to the output stream

  An input file will have an "active" picture, initialized by begin()
  and written to output by end(). Commands that create objects will
  build an object in memory, clip it (if clipping is active), map the
  object and its drawing style using the camera, convert it to the
  current picture coordinates (Cartesian, log_log, etc.), and crop it.
  Objects will still be created and modified with declarative syntax,
  and scenes will still be built up in manual order, but clipping and
  cropping will be effected sanely (in memory) rather than when a path
  is written to output.

  Users can optionally create additional pictures and affinely import
  them into the "root" picture, with syntax similar to ePiX-2. This will
  make legends and other insets feasible.

2. For the benefit of pdflatex users, I'd like to keep the output free
  of PSTricks macros unless the user explicitly asks.  My current idea
  for color filling is to modify Svend D. Pedersen's polygon hatching
  code. With luck, this will permit simulated transparency for filled
  polygons.

3. The following header/source files will change drastically or be
  removed: cropping, curves, globals, Label, objects, output, paths.
  If convenient and maintainable, I'll separate user headers from the
  build headers. And again, functions documented in the manual will
  stay the same (from the user's perspective).

  At the end of the purge, the code will be organized logically, with
  program functionality appearing in an appropriately-named header
  file and implemented in the corresponding source file. (That the
  code is not already so organized is a sordid, frustrating story.)


A few words about ePiX-2: My idea had been to use PSTricks as the
primary output format. Unfortunately, function plots can't be handled
adequately with the binary space partition algorithm I'm using: Mesh
polygons get cut into many pieces (unless the surface is convex), and
LaTeX runs out of memory. (However, ePiX-2 is good with arbitrary
curves mixed with polyhedra containing only a few dozen polygons. It
just doesn't have any high-level interface, so source files must be
written in terms of primitives. The image gallery is up-to-date.)

At the moment I have two ideas for avoiding LaTeX memory overflow:

(i) Use raw PostScript as primary output format.
  Pro: Essentially no limit on image quality (can draw surfaces that
  nearly look raytraced).
  Con: Can't easily insert LaTeX code into file; perhaps overlay
  separately-compiled labels?

(ii) Use a more naive object-hiding algorithm for parametric surfaces
  that doesn't cut mesh patches unless they actually intersect some
  part of the scene. The new ePiX-1 "surface" functions are in part a
  proof-of-concept.
  Pro: Should work (given experience in ePiX-1).
  Con: Will make the internals messier, and probably slower.

It could also be that I'm writing output files unoptimally; I'd be
very happy to hear any ideas on the subject.

--Andy

Andrew D. Hwang                 address@hidden
Department of Math and CS       http://mathcs.holycross.edu/~ahwang
College of the Holy Cross       (508) 793-2458 (Office: 320 Swords)
Worcester, MA, 01610-2395       (508) 793-3530 (fax)