Long-term design goals for ePiX

[Andrew Hwang <ahwang@radius.holycross.edu>]

Here is a not-necessarily-organized list of thoughts and goals for the
future:

0. Why the peculiar capitalization? There's no good answer. Partly it's a
  play on TeX, of course, and on (e)epic (the LaTeX styles), as well as a
  pidgin abbreviation of electronic pictures. It was a short, punchy name,
  to use marketing-speak; only later did I discover that epix, EPIX, Epix,
  and ePix are already in use as trademarks.

1. A few things about ePiX obviously need improvement:

  a) The eepic style does not handle dashed or dotted lines ideally; the
    spacing and dot/dash size are uneven, and adjacent segments do not
    always match end-to-end. Metapost might be a better output format, or
    the eepic.sty could perhaps be improved.

    Perhaps relatedly, paths with a large number of points are noticeably
    not smooth at high magnification. I don't know where this round-off
    error is creeping in. Obvious candidates are the ePiX output itself,
    LaTeX (which only does integer arithmetic), or Postscript. If the
    problem is LaTeX's dislike of floating point numbers, ePiX should
    perhaps be re-written accordingly.

  b) The program is not a stand-alone binary, a limitation that restricts
    potential users' access. For example, a Windows user asked about using
    ePiX. While I think this is technically possible, it is not likely to
    be easy. My suggestion was to install the deLorie port of the GNU C
    compiler, then to compile Bash, and finally to try to install ePiX. I
    have no easy way to determine if this will work or not.

    Making ePiX into a stand-alone binary is more effort than I am willing
    to invest personally, though it might make a good student project.

  c) The internals are not sufficiently modular, and substantial design
    discussion is needed. If ePiX is ever to become 3-D capable, file
    parsing must be separated from output generation, for example. This is
    true even if the program remains implemented essentially as it is now.

2. ePiX has taken a *huge* speed hit in porting to C++ from C. While this
  is not currently a serious issue (normal runs are generally a fraction
  of a second; tenths or hundredths seem about the same), it will become
  more of one as features accumulate, and will be unacceptable in 3-D
  plotting if there is no optimization/improvement.

  There are surely faster ways to pass pairs and triples to and from plot
  routines, but someone more knowledgeable of C++ will be able to see and
  implement them more easily than I.

3. ePiX is at a stage where future design work should be based, to the
  extent possible, on users' experiences and needs. Discussions of desired
  features, as well as ways of implementing them simply and flexibly, are
  likely to be important to the future development of ePiX.

4. Many of the primitives -- simple polygons and curves -- were coded in
  an ad hoc fashion. Again, design discussion is needed, but much of the
  file "objects.cc" surely needs re-writing.

5. Practical development matters: I am waiting to hear from our Dean's
  Office about the College releasing claim on the copyright of ePiX so the
  code can be put properly under the GNU GPL. If this does not happen,
  ePiX may be dead, GPL-wise. If anyone has experience in the matter, I'd
  like to hear about it.

  Assuming the College disclaims copyright interest, I plan to put the
  code on a publically-accessible CVS server, probably Savannah (at the
  GNU project, of course:) though I am not firmly decided on the issue.
  Various parts of ePiX seem like excellent opportunities to get CS
  students involved in a "real-life" development project. I hesitate to
  apply for grant money until the College releases the copyright, though.

  The code is currently in a stable state, to my knowledge. (The last
  freshmeat release garnered no bug reports, which I hope is a good sign.)
  Consequently, there seems to be no immediate hurry to develop further.


This list is new, and its purpose will surely evolve to fit the needs of
its subscribers. For now, anything ePiX-related and of general interest is
appropriate.

Andy

Andrew D. Hwang			ahwang@mathcs.holycross.edu
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)