I’m sure that everyone has the odd infuriating niggle with the software that they use most regularly, but I’m delighted to say that I’ve just found the solution to a problem with CorelDRAW that has been driving me mad for almost 19 years.

That’s how long I’ve been producing a regular quarterly publication based on charts that I tidy up ready for print. Key to this is the ability to resize whole series of elements in the same way. No problem you might think; simply use CorelDRAW’s Transformations palette.

The problem is that this treats the selection as a group. I need to be able to change each object’s scale independently, without changing its positioning, and that’s just not possible automatically. Instead I’ve been forced to apply the transformation to a single object then select all the others in turn (Tab is useful here) and then repeat the last command (Ctrl+R). Trust me, after a hundred or so times, the attraction soon fades.

Transforming objects like this is such a common requirement and it’s such an obvious capability to add to an application that prides itself on its efficiency and productivity, that I’ve always assumed that Corel would fix it in the next release. Some dozen or so releases later, I’m not so sure.

If Corel’s not going to do it, what about the Corel community? I’ve been looking on and off for years, and finally I’ve found a solution. Hidden away in the Sawmill Creek Woodworkers’ Forums – “The biggest and best online community for woodworkers on the Internet” – is the answer.

It’s a simple macro called Transform Each written by Steve Willis based on an original attempt by Manuel Rivas. It’s pretty awkward in use and I strongly recommend that you save your file before applying, and you’ll also need to close and reopen the dialog between transformations. You’ll also have to sign up to  Sawmill Creek to download it (which might help explain the site’s popularity).

It’s certainly not pretty, but it can be made to work, letting you automatically and independently stretch, rotate and flip multiple selected objects. It might only save me 15 minutes every three months, but small efficiencies mount up. I can’t quite believe that I’ve spent two entire working days pressing Ctrl+R.

Sure, there have been some backward steps, too – such as the outrageous display of bigotry that was California’s Proposition 8 – but on the whole, things are getting better. Personally, the prospect of marriage in any form is terrifying, but if it’s available at all, then it should be available to all.

Besides narrow-minded folk, there is another group of people that may have a problem with the whole thing: database designers. I don’t mean to imply that they’re homophobic (although I can’t guarantee that some aren’t), but only that gay marriage is going to cause them a lot of headaches.

Across the world there are millions of databases, programs and online forms that cannot even comprehend the possibility that a man could marry a man, or that a woman could marry a woman. It simply does not compute, and it’s being called the Y2Gay bug.

“To be blunt, the systems aren’t set up to handle it,” says database engineer Sam Hughes in a wonderfully insightful blog post.

“The paper forms have a space for the husband’s name and a space for the wife’s name. Married people carefully enter their details in block capitals and post the forms off to depressed paper-pushers who then type that information into software front-ends whose forms are laid out and named in precisely the same fashion. And then they hit “submit” and the information is filed away electronically in databases which simply keel over or belch integrity errors when presented with something so profound as a man and another man who love each other enough to want to file joint tax returns.”

Hughes goes on to suggest a number of possible fixes, many of which come with their own, unique problems. The field is a young one, and there a lot of unsolved problems – or, at least, ones that are awaiting a sensible solution.

“Perhaps the simplest solution would be to ban marriage outright. Or, better yet, to declare everybody as married to everybody else. But then what would the database engineers do all day?”

A rock slide has blocked off a road between Vancouver and Whistler, the latter of which was holding a Mozilla conference at the time. Those developers who got there early are trapped in, and those who were late are trapped outside. Either way, development is taking a hit.

Ever the resourceful bunch, one developer has thought up a solution.

“Hasham has proposed that we ride bears to Vancouver as a workaround for this bug. Bears can run up to 48 kilometers per hour and Whistler to Vancouver is about 300 kilometers. It would take approximately six hours and fixteen minutes if the bear ridden is running at top speed at all times. Realistically, the time needed is about eight hours. A bear can carry two to three people on average. There are approximately 220 people attending the Summit who flew. This gives us the need of about 74 bears should we boldly estimate that a bear can carry three people. The earliest departure time should be Thursday night.”

That’s the sort of out-of-the-box thinking that grabs market share from Microsoft.