- Left header problem: open Themes/default/aeva/smf2.css and delete all its contents. Reupload. This should 'fix' it. That file is targeted towards the original Curve theme. It isn't guaranteed to work on Curve variations.
Could you post a link to your gallery and make sure guests can view it? I'd like to analyze the code and try to find a better workaround.

- I can parse the BBC in the description. I just forgot to do it... It's only a temp thing anyway. I'm planning to cut the description to avoid having too long descriptions below the pic. (Although I'm not sure yet, since you can get the whole pic by clicking the Zoom link and then clicking the Expand icon.) Will be in beta 6 (the parse_bbc.)
Quick fix: open Aeva-Subs.php, search for

' . $i['desc'] . '
Replace with

' . parse_bbc($i['desc']) . '

- Interesting theme, given that it uses the RC3 code style (hence, doesn't need the smf2.css compatibility CSS). It's by Aaron, you said? That would explain... Since he's a dev. Why is it credited to 'Steve Cook', then?

- No, I'm not planning to release many betas in February... January, yeah it was needed because it still had a lot of bugs in many areas. Right now it's stable I think. I'm actually considering going RC now. Which would mean postponing some of the big new features for later (user settings and Highslide slideshow among others), but would encourage SMG users to upgrade, too.

- Long words: my string cutting function has a word cutting feature, too. Actually I really think I have the best string cutting function I've ever seen, lol. I refined it for months and months. You can have a look at it if you want (aeva_cutString()), I don't mind if other people want to use it.

Oh, cutString is not all that hard to understand...

- If the string is empty, it returns a "..." to make sure it's clickable if there's a link around. (This causes a few issues with album descriptions becoming "...", I need to fix that.)
- If we don't want to test for multibyte strings, we simply cut the string and make sure to remove any half-cut entities at the end of the string. It's the easier version, it doesn't test for long words.
- If we need the string to be parsed in the end, we do it now, so that HTML tags can be correctly stripped later...
- Now we mark all entities and HTML tags as a single special character, into a work string. (Note for myself: tags should simply be stripped, rather than reduced to a single character. That makes 2 wasted bytes for self-closing tags...)
- If that string is short enough, we return the original, parsed string, as it's shorter than what's required on screen, even though the raw string is longer.
- Then we store all of the entities, HTML tags and special characters into an array.
- Then we cut the work string. (Hmm, maybe I should use mb_substr on this..........)
- Time for long word check: for all words that are longer than the desired maximum word length, we add a ­ entity inside them to break them into two words in case it doesn't fit in the final HTML rendition. ­ is very useful, because it only shows up when needed.
- Now we're done with the string cutting, we simply restore the entities and HTML tags...
- And if there's a hard limit on the string size (for instance, if you want to store it in a 255-byte VARCHAR in the database), we cut the string again and strip all half-cut entities from the end.
- And voilà !

Obviously there are a few issues which I mentioned above, and never considered before... No biggie, but still...

No problem.
Latest svn rev has a small upgrade to the function (thanks to the analysis I posted above.)
I didn't touch the html tags though, because it was too complicated. Two wasted bytes is fair enough, I'm not doing several extra preg_replaces to "save" them.