Kepler

tasks remaining before Batik SVG rendering is ready for primetime:

1) ASSIGNING ICONS
Icons can be assigned in actor moml, or can be assigned in the actor's java
code. Assigning in moml means icons will show up for newly-created workflows,
but not for old workflows. [Note that some actors can't be set via moml (eg
EML200 datasource), so would need to add some to java code anyway]

Adding icon paths directly to the actors' java code (note that existing svg
icons are currently defined in java code) means icons show up for all actors, in
new and old workflows. Could move actual actor->svg icon mappings into a
separate settings file? Or would this cause too much indirection and add
complication?

2) MEMORY USAGE
Currently, if Batik has to display more than about 150 SVG icons, it causes a
JVM crash with an OutOfMemoryError. This is also an issue when showing actor
thumbnail icons in the actor library, since these are also rendered using Batik.
So for example doing a search for a very common term that returns many actors
(eg "a") causes an OutOfMemoryError.

Have looked for obvious places to save memory, but now i think we're just
limited by what batik can do. Obvious solution is to start caching icons, since
many of them may be the same, yet they all get rendered from scratch

3) BACKWARD-COMPATIBILITY
- Need to add code so old SVG icons are translated to have their origin at the
top-left corner. They are currently cropped when displayed in batik, because
Ptolemy's default origin for svg components is at the center of each actor icon,
whereas the svg/batik standard is to have the origin at top-left.

4) TEXT WRAP:
In EML simple example plot, text at bottom is rendered using SVG, and it
does not wrap, but extends off the screen. (text did wrap in the old-style svg
handling). Note, however, that if annotation actor is re-created and text is
pasted in again, it does wrap in the new instance, so this is really just a
backwards-compatibility issue

5) SMALL ICON:
getIcon() method in XMLIcon works, but its success seems to be linked to the odd
tree refreshing behavior described in bug #1843. When 1843 gets fixed, we may be
able to make getIcon() more efficient/intuitive, and this may in turn save some
memory usage (see item (2) above)