mezzoblue

#!/bin/sh

commits=`git log --pretty=oneline | wc -l | sed -E 's/ +//g'`
echo "Committed revision $commits."

mezzoblue

rm -rf `find . -type d -name .svn`

mezzoblue

//  PROBLEM
//  so I've run into this at least twice now, where I want to loop through a single 
//  "0 to whatever" range of numbers, but within that loop use the current iteration to 
//  address a 2D array.
//
//  this is in Processing, so the actual use case is creating a 2D grid of coordinates
//  from that single range of numbers. Usually I do it with two loops, ie. loop
//  through i and then loop through j within that loop. But I'm finding cases where
//  I want to loop through just i, and derive separate X and Y coordinates from the 
//  current value of i. Easy to do if i is a square, but what if it's irregular?

mezzoblue

I'm working on a client-side image processing library, prospectively named PaintbrushJS. 
I plan to develop in the open on GitHub, there are just a few loose ends to clean up 
before I push the initial source. This is the biggie, since I don't want to change it 
after I make a decision.

It would be helpful to read my description and subsequent comments on here to get the 
gist of the problem:

http://dribbble.com/shots/45454-Canvas-Effects

mezzoblue

I prefer a Monospace font over any and all Proportional fonts!... i.e., the two
MAIN FONT CATEGORIES into which all other fonts can-- and should!-- be grouped!
But... there's a systemic problem with how FOSS-based Text Formatting suites
(leaving aside, Closed Source/ Closedware suites!) render Monospace, when
incorporating Superscript or Subscript (SS/ SS), graphic boxes, and images (but,
etc.!)!

Why... in a Monospace Format... when placing superscript (or subscript)
characters in LibreOffice (but also, in other FOSS-based programs such as Apache
OpenOffice, and AbiWord!), does the "normal point size" typed below and above