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.

#include 

int main()
{
    printf(”Hello, world!”);
}

Mission

The CodingAway mission is to collect and share the author’s 23+ years of experience in the software development world and high-tech business.

Blog’s Target Audience

CodingAway is written for people interested in technology, software development, software engineering practices, coding tricks, devices and in general anything that has to do with the high-tech world and its ways. If you consider yourself a geek or a high-tech professional or enthusiast, this is the place for you.

The Author

It was 1983 when the movie “WarGames” came out. It was that movie, believe it or not, that fascinated me to the point of changing and shaping my life forever. If you watch the movie today you’d find it cheesy and almost embarrassing, but at the time, when I was 11, it completely captivated me.

Around that time my aunt was buying an encyclopedia. As gift from the publisher she received a small home computer, which was quiet fashionable in the mid ‘80s. It was an Acquarious, one of these many unknown failed attempts that never made it big. A home-computer with rubber keys, an overheating problem and a cassette player as a storage device; one of these unfortunate competitors of the Commodore C64, that at the time dominated the low-budget computer market.

Since my aunt was (and still is) completely unable to deal with technology, she gave it to me. I was 12, and that cheap cheesy machine started it all. I skipped the stupid little games that came with it, and started learning the simple Basic Language of the built-in interpreter. Almost immediately I decided that Basic was not enough for anything serious, and I started studying and coding with Assembly. On home computers in that era you would typically code in assembly with a bunch of “poke”, “peek” and “data” Basic instructions that would load the machine codes directly into memory for execution. Scary, but it worked.

Not long after that I purchased a used Commodore Plus4, which was a heck of a lot more powerful and fun to use. It came with a word processor and a spreadsheet built in, and an excellent Basic interpreter. Painfully saving money week by week, I bought a 5″ disk drive, and kept coding away in Basic and Assembly. Eventually I moved to an Amiga 1000 (which I hated), and not long after to a IBM 8088. From there I kept upgrading with the various INTEL chip generations (V20, 8086, 286, 386, 486, Pentium, etc…). I worked on a first software development project for a customer when I was 14, in order to raise some cash to buy new and better technology (and go to movies and have fun), and never stopped since.

Well, to make a long story short I have been writing software everyday for well over 20 years now, and I grew up coding.

Probably due to this growth so close to technology, I felt at times that I lived in a world that was border-line with mathematics and perfect sciences. I often wrongly assumed that there was always a best way to solve any solvable problem and that it was always possible to identify not solvable problems and work around them with approximations. This sometimes led me to assume that we live in a time where science can find answers to most problems.

Well, I am changing.

I experience everyday that trying to find the perfect answer or ideal solution is impractical and unnecessary. The more I mature in age and experience, the more I realize that practical and achievable solutions are often found thanks to the experience and intuition of the engineers, and not thanks to some well known procedure that can be efficiently thought to others. For this reason, in general, the more experienced an engineer is, the better the solutions are and the quicker they come to be.

This makes software engineering more a form of art than a perfect science. Even if the basis of engineering is in well defined theory and theorems that have been proven mathematically, the success of the application of such theory and theorems in the real world is completely reliant on the skills of the people that do the work. No book can teach you how to apply theorems and theory, no book can truly and practically teach you when to pick an algorithm instead of another. Books and theories can give you an idea, but the efficient and practical application is really a form of art and a product of intuition. Almost a trade.

In this context, I define “art” as the application of procedures and theories based on experience and the artist unique perception of the world, to solve practical problems in a universe governed by laws that we don’t completely understand.

I am always amazed when I realize how much art is involved in any engineering filed, and how much engineering and science is necessary in any art field. For example a painter or a sculptor that wants to excel in the painting or sculpting of the human body, needs to study human anatomy in details and became an expert in the functioning and interactions of the body muscles and bones. Only doing so gives the artist enough knowledge to be able to visually recreate something that is close enough to reality to be considered pleasant and just right to human perception. Leonardo da Vinci knew this. Given that not much material was available he did first-hand research on human anatomy, risking his life and reputation in the process.

On the other hand, the practical application of medicine and surgery is so much based on art, steady hands, intuition and experience that is barely a science. Yes, true, surgeons need to be trained and know the theory very well, but the actual application of the theory and the process of performing a surgery is really a form of art that is susceptible to human error and miss-interpretation of cause and effects. Much like sculpting and painting! Also, a good doctor or a good surgeon is usually able to create a trust and a connection with the patient, which improves the success rate of medical treatments and surgery. This makes doctors very close to artists, in the sense that they are able to direct human perception in a particular direction, beneficial to the achievement of the end-goal.

I am always amazed that engineering and trades, science and art, mathematics and intuition, are so close in nature, if not one and the same, with a different accent and presumptions.