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

[epix-devel]

Hi,

Terrible weekend so I am afraid I didn't get any development work of thesis 
written... I did get some time to think about the ePiX stuff quite a lot and 
form some ideas on what *I* think would be good. I hope this is useful but I 
would also love to hear more from other interested users.

On Friday 05 January 2007 17:26, address@hidden wrote:
> 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.
>
Not sure if I understand the versioning scheme but wouldn't it be more 
transparent to call is 1.1 as it seems there are some large changes being 
made rather than small incremental changes?

> 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.
>
This sounds fantastic from my point of view, especially introducing the power 
to easily produce graphs with insets and legends. In my particular area of 
work insets are used quite frequently as well as figures with graphs stacked 
on top of each other or side by side. I have used 2x2 graphs with axes lined 
up for direct comparison between the four graphs too.

> 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.

Does this still give colour output? I am unfamiliar with the polygon hatching 
code.
>
> 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.)
>
I would love to see this and I think it would aid adoption. A well defined 
interface/API which remains backwards compatible is important to many. 
Toolkits such as Qt only break API in major releases, minor releases do 
however add new classes/interfaces.
>
> 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?

I think this would be a great solution if it would be possible to overlay 
LaTeX compiled labels using the same coordinate space. This would allow for 
more point symbols, greater flexibility in filling/colouring whilst retaining 
high quality output figures with well typeset labels that could easily be 
converted into other formats.
>
> (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.
>
Is it possible to separate the backend output a little? It may even be 
possible to retain both in that way with a base class inherited by all output 
backends. I know it means designing another API, but if it is not user 
visible then it would be less critical maintaining a stable API.

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

I am just starting to learn about optimal methods for outputting graphs. 
Something like ePiX is great where a user can create an ePiX scene for a type 
of plot and quickly change input files, run it on new data and produce very 
accurate figures which look great in LaTeX.

I am just starting to dig through the code now and figuring out how it works 
so that I can help with some of these new features ;) Hopefully my thoughts 
are helpful.

One other thing I thought of was that all graphs should refuse to plot points 
outside of their bounds be default - it seems very unusual to see points 
outside the graph bounds being plotted but that change should not be 
difficult to add.

Thanks,

Marcus