I've been researching texture atlases today. Pretty interesting stuff I must say. It seems there are two approaches to packing the texture. The more complicated one is to implement a bin-packing algorithm to achieve fit all the textures into the smallest space possible. The easier, though likely less efficient method in general, is to just use a grid, with each texture taking up the same amount of space.
For groups of textures, like fonts, this second method seems well suited, since each font character is about the same size (especially for monospace fonts).
What I'm wondering now is what the benefit of a grid, say, 16x16 to store 256 characters, instead of a 256 item column of textures. They would require the same amount of memory to store, but the column would only require a single coordinate to find the texture (or three if you also need the height and width).
@philipwhite In my experience since the grid approach is usually all about convenience/simplicity, a close to a square shape also makes it convenient for artist to work on the atlas directly using ordinary image editors. Otherwise if you are using atlas generating tools, you'll usually go with some kind of packing algorithm, which will usually trim any sort of padding from each asset and store it as an offset, making even monospace font glyphs worth packing. That's why you won't commonly see long thin atlases, and when they do come up they are often themselves packed into a bigger atlas, which would be squarish either for packing purposes or convenience of manual editing.
If untrimmed 256 glyph monospace font is all you need, no reason to make it square.
