The Red Frog Blog

Because it’s Halloween:

Michael Jackson’s Thriller

Oh, and the original.

If you are on a Mac and using Firefox or Safari to view our blog, you might notice that the font weight here is a bit crisper than the rest of our site. You can also see this difference on some of our sites that use light text on a dark background, like The Renaissance and Camp Roseland. Safari and Firefox (Mac) render default fonts a little bit chunkier and bolder than other browsers and generally bolder than we like in our designs.

Here is the difference in the font weight (on our blog) before and after:

Normal (A Little Thick)

Crisp

Why do the fonts display this way? A good example for Safari is explained on this page, Thin Is Always In. The screenshots show that on a Mac the anti-aliased font comes out thicker. The difference is particularly obvious with white text on a dark background.

So, how do you make your font less bold? Unfortunately, the only real solution is a hack, which may cause other elements in your site to display incorrectly.

For Firefox, the hack to implement is opacity, which means adding to an element the style:

opacity:0.99;

Here are the disclaimers:
If you add the opacity to the body tag, it will affect all text evenly, which is desired, but can also affect elements within the body, increasing their opacity. This may cause background images to display more lightly and appear as a different color. Another solution is to apply the opacity to all text elements in your site (headers, paragraphs, links, etc.). Make sure that you apply it to all text elements, otherwise when you scroll around the page and over text, the font will change shape.

For Safari, use a text-shadow property:

text-shadow: 0 0 0 #000;

This hack adds a dark shadow to the font and imitates reducing the thickness of the letters. This hack seems less sensitive to font style and looks like it can be applied site wide to the body.

Enjoy crispy fonts!

After upgrading to the new CakePHP pre-beta that was released yesterday, I noticed that the excellent othAuth component 0.5.4.5, which we use here as part of our user Authentication process, was broken. Part of this was expected, as the new release of Cake has moved away from PHP defined constants, to the new Configure class. Essentially, the othAuth component was looking for the CAKE_ADMIN constant for admin routing, which no longer existed.

Here’s what I needed to do to make othAuth work again (I assume you’ve set up othAuth in the way described in the Bakery):

First, in your app_controller.php file, in the beforeFilter function, add this line above the rest of the othAuth initialization:

        $this->othAuthRestrictions[] = Configure::read('Routing.admin');

And remove any references to CAKE_ADMIN in the $othAuthRestrictions variable.

Then, in the oth_auth.php component, replace all references of:

     defined('CAKE_ADMIN')

to:

     Configure::read('Routing.admin')

and change all remaining occurrences of:

     CAKE_ADMIN

to:

     Configure::read('Routing.admin')

Most of these occur in if-then statements throughout the component.

The last thing I had to do was replace some model save actions. Specifically, if you’re using the standard othLogin, I needed to replace the following (line 328):

     $res = $UserModel->save($row,true,array($this->user_table_last_visit));

with two new lines:

     $UserModel->id = $row[$this->user_model]['id'];
     $res = $UserModel->saveField($this->user_table_last_visit,$row[$this->user_model][$this->user_table_last_visit],true);

Before, it was INSERT-ing a new entry with just the last visit information instead of updating the current user entry. When logging in a second time, I would receive a duplicate entry error from this. Switching from save to saveField helps guarantee that we’re UPDATE-ing the database, instead of INSERT-ing. I imagine you’d have to make a similar change if you use the naoLogin function.

After the above changes, everything worked once again.

Around the office, we like to clean up things up a bit when we get a chance. From our recent equipment upgrades, to the rearrangement of the Cave (I’ll let Tyler tell you about that), we like to do what we can to make little improvements around the office. I noticed recently, as I am sure many other Commons Cam viewers did, that the glare on our camera gets quite strong around mid-afternoon, inhibiting afternoon glances at the many Commons passer-byers. You can even see the glare in our Ithaca Festival time lapse. Although we didn’t clean it up in time for the Apple Festival, the morning after we were motivated to get out our elbow grease and we sent Tyler out the window to make it sparkly clean. We also covered the computer its sitting on with a dark cloth. Here you can see the difference it made.

These are images captured by the Commons Cam between 4:00 & 4:30.

Before:

After:

Stay tuned for more about the Commons Cam and other office happenings!