Bug: a88/492

PuffinPlot's current graphics export options are a little unsatisfying:
there are two options each for PDF and SVG export, since I added FreeHEP
export when a reviewer of the PuffinPlot paper complained about problems
with vector export using Batik and iText. We thus have three different
libraries which between them produce two different variants of each
format. Clearly it would be better to have one well-tested, *reliable*
export option for each format. It would also be good to add EPS export,
which might be more reliable than PDF or SVG for import into Adobe
Illustrator.

There are a couple of promising vector export libraries which might
solve some of these problems: jfreesvg and vectorgraphics2d. The
first only exports SVG; the second, PDF, SVG, and EPS. Both of them
are free software, and both are very compact compared to the current
libraries -- this gives me a better chance of being able to correct
any deficiences myself, since the source code will be more navigable
than e.g. Batik. (It will also cut PuffinPlot's download size a bit,
but most of the bulk is Jython so the overall effect won't be huge.)

For EPS export there is also http://www.abeel.be/wiki/EPSGraphics and
https://github.com/matmas/java-eps-graphics

It would also be worth doing a more thorough web search for other
options: evidently a lot has happened in this domain since I last
evaluated the available libraries.

I've performed some tests with jfreesvg, vectorgraphics2d, and
orsonpdf, as well as the three existing libraries. The biggest 
problem appears to be superscripts in attributed text objects.
Only FreeHEP handles them correctly; other libraries either ignore
them or render every attributed text object as a path.

The evaluation suggests to me that I should keep FreeHEP and drop
the other two existing libraries (which seem to have inferior
performance). I should also add the EPS and EMF backends for 
FreeHEP export, since these formats might be more tractable
than PDF and SVG for many users, and with the main FreeHEP library
already included the extra backends are relatively lightweight.

The most compelling feature of JFreeSVG is the ability to explicitly
control grouping via hints. This would be very convenient for 
grouping the elements of each plot, and none of the other libraries
can do it. Batik puts everything in one group, which isn't too
inconvenient. Batik creates bizarre subgroups of seemingly 
unrelated elements, which necessitates full ungrouping before 
any useful editing can be done. Despite this, I still think the
best choice is to standardize on FreeHEP for now: the correct
attributed string handling and multiple backend support are heavily
in its favour.

Last comment should have read: *FreeHEP* puts everything in one group
(and Batik creates bizarre subgroups). Also, on latest test, Batik
SVG export seems to produce an incorrect page size.

Another note: FreeHEP SVG seems about three times the size of equivalent
Batik SVG. Looking at source, this may be due to much larger (excessive?)
number of decimal places used for positions in FreeHEP output.