You're not the only one playing around with that idea... :-)
Currently it would be difficult, not so much due to the rendering capability but more due to the lack of full implementation of the TextMetric object 1).
The standard specify the object like this:
interface TextMetrics {
// x-direction
readonly attribute double width; // advance width -- only one implemented (!)*
readonly attribute double actualBoundingBoxLeft;
readonly attribute double actualBoundingBoxRight;
// y-direction
readonly attribute double fontBoundingBoxAscent;
readonly attribute double fontBoundingBoxDescent;
readonly attribute double actualBoundingBoxAscent;
readonly attribute double actualBoundingBoxDescent;
readonly attribute double emHeightAscent;
readonly attribute double emHeightDescent;
readonly attribute double hangingBaseline;
readonly attribute double alphabeticBaseline;
readonly attribute double ideographicBaseline;
};
* At current time of writing.
You would need most of these properties to be able to do advanced typesetting (as well as bearings).
There are ways to get around this by using a selection of typefaces/fonts and use other platforms to run through the typefaces and store the typeface's characteristics such as those above as meta-data in em units.
The rendering capability and performance can be solved in more than one way by smart (image) caching and clever setup of the font you intend to use - all on client side - and is not really an issue IMO (but topic is too broad to cover here). Remember that the look on the screen would be a preview (at an 72/96 arbitrary DPI/PPI versus the typical 300 DPI for prints).
Even if freetype is accessible via node...would it allow realtime
typesetting or will it always feed the end user a static rendered
image/result on the page/canvas?
This approach would only introduce another delay in context of real-time use (server render + bitmap transfer to client) which is probably slower than rendering the internal paths of the glyphs using canvas directly.
You can perhaps use it to render cached glyphs (for consistency on all browser platforms but not for real-time rendering) provided it also gives you the glyph metric data, or you would have a hard time to be able to place your glyphs correctly and accurately on the screen.
And also as a side note: don't forget that you would also have to have a target file format (which means you also need to write a parser for such format) to store your document structure in (ie. ODF, PDF or some other well known and supported format).
As a tip: Take a look at the PDF.js project which Mozilla Firefox uses as an internal PDF parser and viewer which can show one way of organizing and structuring all these objects for rendering to screen (I would not recommend a pseudo-text format as PDF for internal handling but check it out for the sake of structuring a type-setting document).
1) We can only speculate (I know I have) why the TextMetric is not yet available as the data is already available internally from the text render engine and it should be a simple matter of mapping those numbers to the TextMetric object associated with the current typeface.
If it has strategic reason and that "some" wants to be ahead when it's first released with an online more advance "WORD/DOC/WRITE"; I don't know, but lets hope the data will be available in close future. In the mean time a LUT (look-up-table) with meta-data for predefined fonts could be one way to go for the metric part.
