Photo of a door with a sign that says This Is Not a Door.So, remember this photo of a door labeled “This is not a door?” Last year, someone else sent a picture of the same door to FAIL Blog. Then a week ago, someone submitted mine to Friends of Irony, where Katie spotted it a few days later.

Here’s where things get interesting.

On both sites, people were absolutely convinced that it was “obviously” photoshopped.

*headdesk*

No, it’s real. It’s in a small business complex at the corner of Newport Ave. and Irvine Blvd. in Tustin, California. You can go there and look if you want. And of course there are the two photos taken from different angles.

The obvious conclusion is that people don’t really know how to tell whether a photo has been manipulated. At least on FAIL Blog, some of the doubters had reasons, even though they amounted to not understanding perspective.

I was tempted to post a comment linking to this XKCD strip (My hobby: insisting that real-life objects are photoshopped), but settled for requesting a photo credit instead.

In the decade I’ve been using Linux, it’s gone from something that required lots of technical know-how just to set up, to something that (in its major flavors) can auto-detect most hardware and provides friendly GUIs for most configuration tasks. But every once in a while, I have the kind of experience that would turn a new user off of Linux. Usually because Fedora has decided to change something during an update.

In this case, it was a digital camera problem. Since we bought our Canon PowerShot SD600 last December, I’ve used KDE’s digiKam to transfer and manage the photos. DigiKam detected the camera and accessed the photos right out of the box, no configuration needed beyond telling it to remember the model. But something changed in the last two weeks, and last night I started getting an error message: Failed to connect to the camera. Oddly enough, it could still detect the camera when it was connected. But it couldn’t display or download the images.

I searched all over, hitting dead end after dead end, until I got a hint that it was a permissions problem. Continue reading

Today I was trying to fix a problem in a section of a website that hadn’t been changed in roughly 5 years. The page in question retrieved data from a database and filled out an Acrobat form using FDF. Under some circumstances, Adobe Reader would generate an error message, “Expected a dict object.” Then it would freeze, and crash the web browser for good measure.

This site was built with ColdFusion, and used a then-freely-available library called PDFFormFiller.cfm (I can’t find any sign of it now) to generate the FDF code. After saving the offending FDF to a file (eliminating the browser as a factor), I started manually editing the code to see what happened.

The problem turned out to be parentheses appearing in the form data. FDF uses parentheses-delimited strings, and it was finding ) in the code and trying to parse what was left as FDF tokens. The solution was simple: just escape the parentheses as \( or \). Continue reading