Hm, this somehow slipped under my radar.
As for the copyright issue: had you asked me, I certainly would given the permission to reuse parts of my code - gladly so. However, since my code is inefficient and sloppy, I wouldn't suggest so. You are free to gander at it and facepalm at my epic fails. Heh.
Shouldn't be too difficult to develop a proper spritefont plugin for a capable developer, however. In theory, it is a fairly simple thing: the text is stored and manipulated in abstract format (as array data), then the rendering function just iterates through array to draw each glyph as necessary.
There is texture caching to consider for performance (it only redraws whenever the text is changed). Perhaps double-buffering would make sense; one buffer to store drawn glyphs and other to manipulate the whole resulting texture, so that changing scale/rotating/etc. wouldn't require redrawing each glyph. I've used an in-memory canvas, which was causing issues with CocoonJS earlier releases.
But:
The plugin should not allocate any images or create any canvases other than the single sprite font image, to minimise image memory use. Note Mipey's plugin allocates additional images or canvases; this should not be done in this plugin. It should be possible to draw arbitrary strings directly from the single sprite font texture. It must support both canvas2D and WebGL renderers. It must support Construct 2's layout-by-layout texture management in WebGL mode (the Tiled Background object is a suitable example of how to do this).
This makes things kinda... challenging. There are two different textures to consider: the glyph sheet containing all glyphs to draw and the resulting image that contains the drawn text. With single image condition this is kind of difficult to accomplish. The only way to accomplish this would be to read glyphs from external source (that is, another object, such as a sprite containing the glyph set). I have never managed to wrap my head around the inter-object intricaties, however.
Then there is the issue of utf-8 fonts, which can be resolved by mapping glyphs to ANSI-compatible identifiers (using more than one character to describe a character). For that, however, proper support must be prepared.
All in all, considering all that, I expect the Sprite Font borne of this contract will far surpass my abomination. The only reason I dropped SpriteFont was my own lack of expertise to resolve issues, really.
Good luck!