It’s honestly surprising that Google engineers haven’t bothered to whip up a MS Outlook plug-in for this purpose, but rather than continue dreaming, let’s look at the various methods that have been introduced by independent developers instead:

• RemoteCalendars (RC)
  An open source plug-in for Outlook 2003, RC provides you the necessary functionality to subscribe and sync with remote calendars, such as gCal. However, getting it to work right isn’t a walk in the park. You will want to refer to a step-by-step setup guide, which should then be followed with publishing instructions over at the official documentation. Even then, you mileage may vary.

• ScheduleWorld + SyncML/Funambol Outlook Plugin
  This approach involves using ScheduleWorld (SW) - a free web service (at the time of writing) - as the middleman between gCal and Outlook. For step-by-step instructions, refer to a detailed guide on this approach. Note, however, that you no longer need to copy your calendar’s Private iCal Address to SW as SW automatically pulls your calendars via your gCal User ID and password. Also note that SW does not automatically/periodically sync with gCal (though a script to do that seems to be available).

• CompanionLink for Google Calendar (CLGC)
  A pay-for software (US$29.95 at the time of writing), CLGC is an independent software which allows you to synchronize gCal with most, if not all, of the latest mobile devices and Personal Information Managers (PIMs) available. However, not only is it not free, it seems to be bug-ridden as well. Moreover, you can only sync your default gCal at the moment, so syncing multiple calendars via CLGC is currently out of the question. So, like RemoteCalendars, your mileage may certainly vary. Therefore, it is suggested that you try their evaluation version first before purchasing a copy.

Clearly, a perfect two-way syncing solution for gCal and Outlook has yet to be developed. So, any developer that does come up with one will certainly be blessed with gratefulness (both verbal and monetary).

In particular, we’ll be looking at web-based tools that automatically reduce the size of your CSS files - whether by removing whitespace, removing comments, and/or merging classes and attributes. In alphabetical order, they are:

• CleanCSS
• Clean Compress
• CSS Optimiser
• CSS Tweak
• Flumpcakes CSS Optimiser
• Icey’s CSS Compressor

Article under construction.

What about large headlines though? Given their limited quantity on a single page, shouldn’t there be a means to produce beautiful text using custom typefaces? For most web sites, hand-created images are used to replace the underlying plain text headline. While complete typographical customisation is afforded, three problems come to mind.

One: Separation of style and content. Plonking down a plain <img> tag with your hand-crafted image means that your image location will have to be defined within your structural markup, rather than the preferred external stylesheet. Two: Accessibility. Using CSS to define a background image instead results in no alternative text when images are turned off given the lack of an alt attribute. Three: Manageablity and flexibility. Every headline you want to replace with an image will have to be managed individually. Images created by hand and tags assigned by hand. Any change in typeface will require a change in the individual replacement image.

Enter modern text replacement techniques. Some of these attempt to solve all three problems, while others focus on only the issue of accessibility. All, however, ensure that you have an effective, standards-based means to stamp down typography you dictate - completely. There are three categories of methods which comprise modern text replacement methods: Image-based, Javascript-based or Flash-based text replacement.

Image-based Text Replacement

For the most part, these techniques tackle the issues of separation of style and content, as well as accessibility in replacing text with images - both problems highlighted above. But before you assume there is a finished and perfect product ready for instant implementation, here’s how the image replacement camp looks like (in some order of development):

1. Classic Fahrner Image Replacement (FIR)
   First popularised by Douglas Bowman (with his original tutorial), this technique is the building block upon which almost all image replacement techniques thereafter have been developed. It has since been deprecated, though the concept remains important to know.

   Fundamentally, classic FIR involves nesting one set of tags within another, using the inner set of tags to hide the text we intend to substitute, and using the outer set to display the image. While no particular tags are required, most nest a <span> tag within a header tag (e.g. <h1>) - with display:none assigned to the <span> and background-image assigned to the header.

   Its weaknesses: Not screen-reader friendly, second tag required (i.e. <span>), plus nothing is rendered when users turn off images, but enable CSS in their browsers.

2. FIR + ALT Text
   Given that the lack of ALT text is the key cause of screen reader inaccessibility (in comparison with the use of a conventional <img> tag), Radu Darvas proposed the use of an additional transparent .gif to hold ALT text. View his original source code.

   Its weaknesses: Besides the requirement of an additional <span> tag like in classic FIR, this method also requires the use of a third html tag, i.e. <img>, to hold the transparent .gif. There is thus little difference between this method and merely plonking down an <img> tag with the replacement image itself.

3. Leahy/Langridge Method
   Two designers, Seamus Leahy and , independently devised an enhancement using overflow:hidden, which allows us to drop the second html tag, i.e. <span>. Screen readers surprisingly show text replaced through this method.

   Its weaknesses: Nothing is shown when images are turned off, but CSS turned on. Hack required to get it working in Internet Explorer 5.

4. Text Shifting Methods
   Three somewhat similar methods using text shifting have been discovered. One by Radu Darvas using a very large negative margin-left, and another by Mike Rundle of Phark using a very large negative text-indent (see Phark Revised which adds a height declaration to squash a Safari bug). The third method at Stuff and Nonsense uses a very large negative letter-spacing. All methods show the replaced text in screen readers.

   Its weaknesses: Again, nothing shows when images are off and CSS is on.

5. Z-Index Method
   By applying a negative z-index on the inner html tag, i.e. <span>, text can effectively be hidden in simple layouts, and yet show in screen readers. It also solves the problem when images are off and CSS is left on.

   Its weaknesses: This method only seems to work on simple layouts. In more complex layouts where multiple elements are nested, the negative z-index puts the element too deep to be visible. Moreover, this method still requires the additional <span> tag.

6. Gilder/Levin Method
   Solving the problem when images are off and CSS is on, and yet working in screen readers as well is a method devised by Tom Gilder and Levin Alexander. This, along with the text shifting methods above, are among the most promising techniques.

   Its weaknesses: Still requires a second html tag, i.e. <span>. Transparent images cannot be used since they won’t hide the replaced text. Code is arguably more complicated than the text shifting methods above.

Of all the methods, only the Gilder/Levin method and text shifting methods tackle two out of three of the main weaknesses addressed here (screen reader accessibility, images off CSS on, extra html tag) without introducing any new major problems into the picture. The former ensures text is shown in screen readers and also when images are turned off and CSS is on. The latter is also screen reader accessible, but does not show anything when images are off and CSS on. However, it does not require the additional <span> tag.

This would thus imply that, in general, the Gilder/Levin method is the most optimal image-based text replacement method available at the moment, considering that it solves the two major accessibility problems, while only leaving us with an additional <span> tag.

Javascript-based Text Replacement

Javascript-based techniques hope to reduce the dependency of image-based CSS techniques on a key assumption: Screen readers can’t handle certain CSS rules, and thus show the hidden text normally replaced on conventional PC screens.

• Javascript-centric FIR
  Pretty much the first full attempt to bring in Javascript to compensate for FIR’s traditional weaknesses, this method by Peter-Paul Koch requires only a small amount of Javascript (~1kb) to handle the text replacement normally done by CSS. Like the image-based text replacement methods above, this one still requires you to manually create the replacement images yourself - unlike the methods outlined below.

  Its weaknesses: Requires Javascript to be turned on.

• Dynamic Text Replacement
  As an extension for the Javascript-centric FIR method outlined before this, this method brings in automatic generation of the replacement image using PHP (plus the GD library). A lot of detail has been taken into consideration to ensure a robust technique, including print-friendliness and flicker-freeness.

  Its weaknesses: On the client-side, it requires Javascript to be turned on, and imposes an ~8kb script overhead. Server-side, it requires PHP, with the GD library installed.

• Scalable Jens Image Replacement (sJIR)
  Built upon the framework of scalable Inman Flash Replacement (sIFR), sJIR attempts to remove the Flash component required in sIFR (leaving only Javascript as the remaining client-side requirement). As a result, sJIR has almost similar requirements to the Dynamic Text Replacement method. Therefore, your final choice between them pretty much depends on personal preference.

  Its weaknesses: On the client-side, it requires Javascript to be turned on, and imposes an ~8kb script overhead. Server-side, it requires PHP, with GD and libfreetype libraries installed.

Flash-based Text Replacement

Only one method exists within this category, but it is one of the most promising text replacement techniques available today. Although it requires Flash client-side, the strong browser compatability of Flash and its high adoption rate ensures that this method can be depended on in production-level sites. Scalable Inman Flash Replacement (sIFR) is currently stable at version 2, though version 3 is already in beta at the time of writing of this article.

Its weaknesses: Requires both Flash and Javascript client-side, and imposes a ~8kb script overhead, as well as a 5-20kb font .swf overhead. Cannot be used in high volume due to the processor overhead involved. Requires Flash developer-side to generate font .swf files (though repositories of free .swf font files are available online).