You can't select the text, it doesn't behave like text (Can't resize it in browser), so what's the advantage over just using images?
It was not meant to behave like text as such. It was a quick before-breakfast response to someone's "how-to" request. Processing.js is a visualization language, not a replacement for browser technology, apologies to those who were expecting some kind of all-singing miracle-link.
It's cool for what it is, I was just wondering if it had some advantage over images that I couldn't yet see.
Well someone requested it as a demo because they are creating an interactive canvas program in which the text being displayed will change every time the script is run. Obviously that makes using images impossible. With regards to using images for the glyphs, it's slower and requires more KBs across the board.
Good for Processing.js, but those desiring a replacement for sIFR or @font-face will be disappointed. Every browser that supports the Canvas does or is expected to support @font-face as well, so there is no advantage there, and the required conversion to SVG only shifts the embedding rights problem one step away from the browser.
Well, true, IE doesn't support <canvas> out of the box, but you can make it support it with something like excanvas.
It was not intended to be a solution to text on the canvas for anyone but people using the Processing.js language. There are already great tools for TTF rendering for websites like Cufon.
When you talk about shifting the rights problem one step further away, I wonder what exactly you mean? Surely the issue is the same regardless of the application layer in which the font's path data is being presented? The only issue being of course that the font's path data is publicly available. Am I missing something?
These tricks don't work in all browsers. For example, I was completely unable to trigger it on iPhone. As 'alternate' browsers become more prevalant these tricks become more risky.
Easy enough to make it work for iPhone though, if that's what you are trying to do.
Should have used mouseClicked() instead of mousePressed() (latter takes you to the href location before the mouse is released). Should also have used the mouseButton variable to determine if it's a left mouse click. As it stands now a right click also takes you to the target page.
Changed the example (and updated processing.js) to include mouseClicked().
True, good point.
Is it just me or does the verbosity of the processingjs code for custom fonts bother anyone else?
What are you getting at exactly? The code in the demo script or the code in the library?
The demo script. Any of the demos as a matter of fact.
Well it really is designed as a low-barrier language. It doesn't have all the shortcuts you'd see in a low-level language. Even though you can use JavaScript in Processing.js, I usually try to make sure my examples run in the Native Java application also, which requires greater verbosity of course.
Updated this.
Never click on a link you don't see where it takes you. You can get goatseed.
Is it possible to show the url in the browser's status bar?
Ironically showing the url in the browsers status bar is automatically disabled in Firefox because for goatseed reasons.