Dan Bernier edited this page Aug 10, 2013 · 9 revisions
Clone this wiki locally


Managing ToDos

Move these into either a) the README, or b) issues.

Documentation and Examples

Generate wiki-page documentation for WordPlacers, WordColorers, etc, from javadoc comments? Auto-deploy them to the wiki svn?

Make a WordCram API cheat-sheet.

Tutorial/blog post/example sketches on:

  • Word.setSize(), Word.setPlace(), etc.
  • Word.getRenderedPlace() vs Word.getTargetedPlace() for troubleshooting, too

WordCrams to Create

The Cathedral and the Bazaar, The Art of Unix Programming

A Blog header from WordCram's source. The odd dimensions will be a good test, and it'll require a text provider that can parse out Java words (variable names, methods, classes, etc) -- along with java stop words. Throw in the example sketches and wiki pages. This is all set, except it needs a TextSource for loading a source folder of java files. Once that's in place, the example can be included with the rest of them, and this can be crossed off.

Plug-in Improvements

Rename everything from Colorer/Fonter/Sizer etc. to ColorPicker, FontPicker, etc. Provide them as aliases for a while.


Pick some really nice default fonts & colors for demos. Look at

Colorers something like's Mono(hue), Complement(hue), Triad(hue, offsetAngle), etc.


An auto-angler that decides whether to rotate a word or not, based on the destination's aspect ratio. If it's wide & short, longer words will be horizontal; if it's tall & narrow, longer words will be vertical. Short words will be random.

double aspect = width / height;
double lenPercentile = maxWordLen / thisWordLen;
//...not sure of the math here, work it out


A placer that renders bigger words horizontally by weight, and vertically close to the bottom -- should produce a right triangle w/ the right angle in the bottom left.

Text Sources

new DeliciousTagsTextLoader(username), new RssTextLoader(url), new TwitterStreamTextLoader(twitterer), new JavaSourceCodeTextLoader(srcDir)

Not sure of this one: API change for TextSources: move WordCram methods include/excludeNumbers, withStopWords, and upper/lower/keepCase onto the TextSource. Rather than WordCram's fromWebPage() and fromTextFile(), it'd just have fromTextSource(new TextFile(path, this).excludeNumbers().upperCase()). Well, that last part sucks. Maybe not.

Make a standard text format for saving (and re-loading) Words, so you can generate your word weights once, and store it (for faster applets).

Allow for MULTIPLE text sources - make the methods additive, so calling fromWebPage('') twice gets them both.

Core Improvements


Get the words to render closer to where the Placer places them. Right now, the PImage the word is rendered to is so large (to account for rotated words), that there's a lot of background color between the point and the first pixels of the word. This makes it harder to effectively code up a WordPlacer, and get the output you want. DONE: switched to java.awt.Shapes, which take up minimal room.

Keep words from going off-screen. Scale the window (somehow) to fit words in, when they run off-screen. There's some basic bounds-checking now, but it could be a lot better.

Try changing the color scheme AFTER rendering it, without totally re-rendering. Try re-laying out words with the same settings.

Arbitrary shapes, like


Try simulated annealing, as mentioned in the blog.

When placing a word, remember which quadrant it's in. When checking for colliding words, check the appropriate quadrant first, to speed things up.


Rename WordFonter, etc to FontPicker, etc.

Add more overloads to the fluent builder API.

Add a method to get the Word at the given (x,y) coordinates. Done, with a naive implementation, without memoization. Seems fast enough for now. If it becomes too slow, try a quad-tree.

Building WordCram

Better unit tests: use Mockito? In progress