[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Long-term design goals for ePiX
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)