Zen doesn't have a rich text editor component of its own and ISC's development of new Zen functionality halted several years ago so nothing along those lines is in the pipeline.
However, I know several Zen adopters who were successful at creating custom Zen wrappers around both the TinyMCE and CKEditor widgets. I'm not endorsing either of these third party tools, I'm just acknowledging that they have been made to work with Zen in the past. I also vaguely recall one user having luck running the Dojo Toolkit dijit/Editor in an IFrame within a Zen page at one point and successfully passing data back and forth through frame references and ZenMethod calls. I'm sure there must be others by now as well. It's not an ideal solution, but certainly something worth investigating before resorting to writing an rich text editor from scratch.
In general, third party widgets that stick to standard HTML5, CSS and JavaScript can usually be "wrapped" as Zen components so long as they are not tightly coupled to some sort of page controller or custom page loader. Widgets based on "highly opinionated" frameworks (such as Angular) or written in non-standard languages that require extra trans-coding steps (e.g. TypeScript) are much harder to integrate and probably more trouble than they are worth as far as Zen extensions are concerned.
Best of luck.
While the <TablePane> doesn't explicitly support the onMouseOver event, there are a few hooks you can exploit to inject whatever HTML5 content you desire.
One generic trick is to use the getEnclosingDiv() method (defined for all Zen components that map to HTML DOM elements). This will get you a pointer into the DOM where you can use JavaScript to add event handlers, append or delete child nodes, and annotate DOM nodes with additional (temporary and/or hidden) information for bookkeeping purposes. Just be aware that a server-side refresh will wipe out any such changes at run time so you need to either pay attention to when those are occurring, or be ready to edit the DOM again (with a onUpdateHandler() or onRefreshHandler()) should your changes get toasted.
In your case, however. TablePane offers a more directed solution. OnDrawCell() is a server-side callback that allows you to inject HTML into the page as the component is being generated on the server. You can define a separate callback for each column and the system will invoke that callback once for every row in your result set, allowing every cell to have unique contents and behavior as desired. (The "Using Zen Components" DocBook section on Zen Tables offers examples of how to use this callback and how to access the underlying query results from the handler).
It sounds like what you want to do is to inject a <DIV> element with a custom onmouseover and (maybe) onmouseout event listeners installed. Give this DIV a width and height of 100% (so it fills the whole cell) and then append whatever visible content you want inside the cell. This can all be achieved with simple WRITE statements or by using the &HTML<> syntax.
The callback to actually process the event can be any visible ClientMethod, usually accessed via the special JavaScript objects, zenThis or zenPage, and can be passed whatever information is needed to determine which image should be displayed and where on the page it should appear.
Hope this helped.
If you're working on a version of Cache '16.2 or higher (or any version of IRIS) you have access to %DynamicAbstractObject (DAO) and its subclasses %DynamicObject and %DynamicArray. While most people know these classes only as our "in-memory model for JSON" they are actually much more powerful than that. DAO was originally designed to be the basic building block for all forms of abstract data modeling; a staging area, if you will, for Sanitizing, Merging, Annotating, Redacting and Transcoding arbitrary data.
The original vision was that data could be procured from a variety of sources (URLs, result sets, classes, globals, external files, etc.) in a variety of formats (JSON, XML, CSV, YAML, HTML, etc) to populate an Abstract Entity Tree (AET), a directed, but schema-less, graph that focuses on the semantic meaning and core relationships of the data, rather than syntactic artifacts introduced by its serialization. Under the AET model, data is organized into nested trees of _objects_ (unordered collections of named items) and _arrays_ (ordered collections of unnamed items). Individual nodes may be added, edited or removed using the DAO API. Finally, the finished AET (or subtrees thereof) may be published (serialized in a variety of formats) to a stream or persisted to class instances (late-binding schema) or directly to globals (no formal schema required).
DAO currently supports kernel level support for serializing to and from JSON. It also has an API for AET node manipulation and ObjectScript enhancements for initializing nodes directly from JSON-like expressions.
Using DAO, you could build up a single abstract data "document" complete with both meta-data and data to populate a variety of classes and/or globals, serialize this to JSON and import and unpack the payload on the target system (either by importing a file or building a small REST service (JSON travels very well over REST without the overhead of building up a full SOAP/WSDL enterprise - this can be especially useful if working on a prototype, one-off or "actual requirements still in flux" situation).
Out of the box, unfortunately, we do not currently ship many of the other nice to have supporting routines (ResultSetToAET(), XMLToAET(), AETToGlobal(), AETToRegisteredObject(), ValidateToSchema() etc.) but many developers have made such contributions on an ad hoc basis (and some are posted elsewhere on this site).
Also, if you have specific use cases in mind, feel free to contact me, I've prototyped quite a number of DAO type conversion and serialization methods over the years, I may have something that can jumpstart your efforts.
[Note: DAO and its support for %ToJSON() and %FromJSON() is a different beast from the %JSON.Adaptor. The latter works like our XML adaptor and generates methods at class compilation time that write JSON syntax snippets based on the static schema of a %Persistent class. DAO processes ORefs dynamically at run time and has no requirement that classes be "JSON enabled" at compile time, and, as mentioned above, with the right glue code, DAO can also be used to serialize/initialize raw globals, result sets, %Zen.ProxyObjects, streams, %RegisteredObjects, $Lists and ObjectScript multi-dimensionals. ]
Hope this helps.