A query - convergence with other Renderers?
| Project: | Dynamic Rendering |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
As this module space is named generically 'render' and the SIFR method is treated as a (the only) plugin, are there any plans to extend into other 'renderers'? Specifically, the signwriter of course is in the same space.
In imagecache_actions I've been asked to keep adding features to the (currently limited) text rendering process, so I'm looking around for some sort of way we can share a common API or at least naming convention or hook set between the diverse renderers, including imageAPI, signwriter, imagecache_actions ... and maybe 'render'?
There may not be a path for it in SiFR/render right not, but if it is to place itself as a generic 'render' package, then perhaps this is where some SPI work can begin.
For no good reason, I also have a SVG renderer in the background I wrote a while ago that may have a place. I'm not sure why or where yet :-/
Just thoughts, wondering.
What, if anything, do you think may be the next 'plugin'?
#1
True, true. :) Well, while we can certainly think about a new or common namespace, I'd like to point out that Dynamic Rendering ("render") was just based on a (very) simplified thought: Stuff like sIFR and other client-side rendering methods like SuckerFish/SuperFish menus, or even the /presentation/ of admin_menu, is solely based on CSS and JS rules, which may or may not be configurable. For example, admin_menu comes just with one look and no options to alter this look. If there was an integration with Dynamic Rendering, the user would be able to configure colors (CSS) and behaviors (JS) of admin_menu. Currently, Dynamic Rendering is still widely based on the former sIFR integration module and hence allows the user to configure styles and behaviors for dynamic text replacements (in sIFR's case, using Flash).
There are already some requests for other rendering techniques:
#261799: Add jITR/DynaText plugin (close to get included as next plugin)
#123718: Add sIFR_lite plugin
#120308: Add sIFR 3 plugin
#224316: Add jQuery sIFR plugin
#301799: Add jQuery Media plugin
...and I've even implemented SuckerFish dropdowns as an experiment some time ago (but never took the time to post it as a patch in the queue). So, while the above mentioned issues all deal with sIFR-alike methods for text replacement, SuckerFish is an example for a completely different CSS/JS-based rendering use-case, where the user wants to configure colors, positioning, and other aspects of the dropdown menu.
There is definitely a kind of overlap with Signwriter, maybe even with Textimage. The current difference is that Dynamic Rendering assumes client-side rendering methods only, and just tries to provide the necessary configuration screens to configure CSS/JS properties and rules for them. However, since I am actively developing a yet-unknown font rendering script similar to DynaText that would basically be able to pre-render images on the server-side already, I completely agree with your intention and thinking here.
Also just thoughts, and very unsure how we could proceed from here.
#2
Although I totally understand the difference in the current client-side job that SIFR does - to a designer, client or user, sifr and signwriter do the same job :-)
If content-negotiation was a reality (it never has been IMO) then we'd be able to switch invisibly between the two methods.
There's a lot of common settings - in the way these utilities are configured - which CSS classes they capture, they define background, foreground colors etc.
So if we were to use a common 'rendering process profile - from which the renderers could do the things they know how to do.
If you've looked at it, the imageapi rendering pipeline is currently the most extensible model I've seen.
I'm not sure about the actual direction here - it may take a bit of fiddling to demonstrate actual code I guess. Common formAPI calbacks for configurations, common Hooks for processing.
I could mock up something that allows import/export of whole effect profile recipes if these could be put into a format worth re-using.
I recently looked into signwriter, and saw it's not really designed to be extended, but I'd like to be able to re-use what it does do for, as I say, my imagecache pipeline.
Yeah, sifr is currently an edge case, but there's potential there.
Still nothing concrete to go on, but I'll see if I can push a few callbacks into the appropriate places when I touch them.