Coding Away

In the last few years I found myself in need to render a font outlined to increase readability or to comply with UI requirements.
In both cases I had a non-outlined font, I had no choice of picking a different one, and I had to render it outlined.

To give you example, I had to render a font like this:

Outlined, like this:

If you are not too concerned about rendering speed (in my case, it wasn’t an issue), the trick I used to accomplish this is astonishingly simple, and very effective. You just need to render the font 5 times in different positions; 4 times with the color of the outline, and one time with the color of the body of the text.

Assuming that you want the body of the text starting at position (x,y) on the screen, the algorithm is:

A) Select the outline color.
1) Draw the text at (x+1,y)
2) Draw the text at (x-1,y)
3) Draw the text at (x,y+1)
4) Draw the text at (x,y-1)
B) Select the font body color
5) Draw the text at (x,y)

Here is an example of the results you get after each draw, numbered as in the above steps. In the example the color of the outline is BLACK, and the color of the body of the text is RED. I also added a background with a color similar to color of the body of the text, to show how outlining can increase readability in cases where you don’t know what the color of the background is (like in cases where the background could be any image).

To make it even clearer for you I did the same thing but this time I rendered the body of the text in gray after each steps 1,2,3 and 4. This way it becomes very clear how the outline is constructed, with each draw, around the body of the text:

In Java, a very simple example of a method that does exactly what described looks like:

public void drawTextOutlined(Graphics g,
                            String text,
                            int x, int y,
                            Color cOutline,
                            Color cBody) {
   g.setColor(cOutline);
   g.drawString(text, x+1, y);
   g.drawString(text, x-1, y);
   g.drawString(text, x, y+1);
   g.drawString(text, x, y-1);
   g.setColor(cBody);
   g.drawString(text, x, y);
}

Variations:

This method of outlining can be used with pretty much anything that you can render in a given color; it doesn’t have to be only text. In some cases it can even be expanded to images. It’s somewhat of a long story, but if anybody cares I can post about that as well.

There are also many variations based on the same concept. For example you can draw the outline rendering the text in the outline color at positions (x+1,y+1) (x+1,y-1) (x-1,y+1) (x-1,y-1) with similar results. You can also try drawing the outline with only two renderings of the text in the outline color, at positions (x+1,y+1) (x-1,y-1) or (x-1,y-1) (x+1,y+1), saving two text renderings and obtaining OK results in most cases.

I prefer the variations presented here, which gave me the best results in the situations I had, but feel free to experiment. There are cases where different variations might give you better results.

Hope you’ll find this helpful.

One of the challenges that from time to time you may find is a program that has to deal with a linked list having a loop.

While this is not a very common situation, it can happen, desired or not, as result of a bug, the particular usage of the linked list in the program or corrupted data.

A classic example of such situation caused maliciously by viruses, is the case of directory loops in the old DOS. As in many other OSs, in DOS directories where nodes of a tree; each node, or directory, had a pointer to each of its sub-directories. A single path such as “C:\a\b\c\d\e” could be seen as a linked list a->b->c->d->e. This is not uncommon, but one thing was particularly bad in DOS 3.1. Nothing in the system was able to deal with directory loops, no even the most advanced utilities.

If you took a disk editor and connected a directory, say “e”, with anything on an upper level, say “b”, you’d cause serious issues. No utility at the time was able to catch such an issue, which was guaranteed to crash any directory crawling program, including CHKDSK. You could keep re-entering the loop ending up with a path like “C:\a\b\c\d\e\b\c\d\e\b\c\d\e”. Some old viruses took advantage of this weakness to create all sort of troubles.

Anyhow, how do you write an algorithm to find out if a list has a loop? Usually people tend to go for a solution like traversing the list, marking each node as they go and, if they found an already marked node, than there is a loop. That solution works, but once you are done you have to clear that mark on all the marked nodes. In some cases this might not be desirable or even possible.

I’d like to present a small cleaver algorithm that detects loops in a list without having to alter the list in any way. I like to call this algorithm “The Rabbit and The Turtle Algorithm”, but I wonder if it has another name (does it?)

The idea is simple: you use two runners (pointers) to traverse the list. One moves one step at the time (turtle), and one moves two steps at the time (rabbit). The two keep running until the rabbit finds the end of the list, or until the rabbit passes the turtle. If the rabbit arrives at the end of the list, there is obviously no loop. If the rabbit passes the turtle, than there is a loop.

Simple, isn’t it? Here a simple implementation in Java:

// ListNode is the type of a node.
// head is a ListNode, head of the list.
// If node is of type ListNode, node.next is
// the pointer to the next element in the list.

01: public boolean hasLoop() {
02:
03:    if ((head == null) ||
04:        (head.next == null)) return false;
05:
06:    ListNode lnT = head;        // Turtle
07:    ListNode lnR = head.next; // Rabbit
08:
09:    while ( true ) {
10:       if ( lnT == lnR )
               return true;
11:       if ( (lnR = lnR.next) == null )
               return false;
12:       lnT = lnT.next;
13:       if ( lnT == lnR )
               return true;
14:       if ( (lnR = lnR.next) == null )
               return false;
15:    }
16 }

Lines 03-04 deal with the cases of (1) an empty list and (2) a list with only one node. In either case there is no loop for sure.
Lines 06-07: talk about injustice! The rabbit starts in front of the turtle already.
Line 10: checks if the rabbit encountered the turtle. If it did, we found a loop.
Line 11: Moves the rabbit forward one step. If the rabbit reached the end of the list, no loop exists.
Line 12: Moves the turtle forward.
Line 13: If the rabbit found the turtle, we have a loop!
Line 14: Moves the rabbit an extra step forward. If the rabbit reached the end of the list, no loop exists.
Line 09: Repeats until one of the conditions above is satisfied.

Hope this is useful.

Sometimes it is useful to find out if a particular integer represents a power of two. You can find that out with a simple trick.

A power of two in binary is represented by a all zeros, except for a single one. For example 00010000 is a power of two (2^4).
In fact you can calculate the n-th power of 2 with:

int power2(int n)
{
     return (1<

If you subtract one from a power of two, you obtain a number which binary representation is a sequence of ones. Example in binary:

00010000 - 1 = 00001111

If you take this number and perform a logical AND with the original power of two you obtain a flat zero!
Example:

00010000 &
00001111
———
00000000

If you have any other number that is not a power of two, this doesn’t work anymore and you’d never obtain a zero.
For example let’s take 18, which is not a power of two.

18 in binary is 00010010
00010010 - 1 = 00010001

00010010 &
00010001 =
———
00010000

Another example. Let’s take 14 which is another number that is not a power of two:

14 in binary is 00001110
00001110 - 1 = 00001101

00001101 &
00001110 =
———
00001100

In general you’ll find that the result of (X-1)&X always contains at least a one… unless X is a power of two! Cool!

For this simple reason you can find out if an integer is a power of two with something like:

boolean isPowerOf2(int x)
{
    return ((x-1) & x)==0;
}

Enjoy!

I keep seeing code to calculate leap years implemented with functions like:

bool isLeap_wrong1(unsigned int year)
{
    return !(year%4);
}

bool isLeap_wrong2(unsigned int year)
{
    return !(year%4) && (year%100) ;
}

These are inaccurate because they don’t take in consideration all the rules of the Gregorian calendar adopted by most countries in the world.

In the Gregorian calendar before the year 1600 AD a leap year was defined as follows:

A year is a defined as “leap year” if it is divisible by 4 but not by 100.

After the year 1600 AD the Gregorian calendar was revised and the leap year defined as follows:

A year is a defined as “leap year” if it is divisible by 4 but not by 100 unless it is also divisible by 400.

This definition is destined to be revised in the future (before 2800 AD) since it is still not perfect; however, in your lifetime you should be fine with it and it is currently the official rule.

Based on this definition, the correct “modern” (past 1600AD) way to find out if a year is a leap year is the following:

bool isLeap(unsigned int year)
{
    return !(year%4) && ( (year%100) || !(year%400) )
}