-
Notifications
You must be signed in to change notification settings - Fork 53
ToDos
Move these into either a) the README, or b) issues.
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
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.
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 colourlovers.com.
Colorers something like http://colorschemedesigner.com'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 outA 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.
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.
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 tagxedo.com.
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.
Better unit tests: use Mockito? In progress