Although I’m no longer using XNA, I dabbled in it for quite some time, and learned a great deal. For me, one of the trickier parts was implementing custom fonts. Although I’ve since moved on to developing in Unity, I wanted to make a quick write-up for my old FontBuilder project. It was a pretty cool tool at the time, and it taught me a lot about scripting for Photoshop.

Font support in XNA was extremely limited, and if you wanted to use any custom or stylized fonts, you were pretty much required to create a bitmap sprite sheet of your font. Some tools were already created for doing such a thing, like in the link I just provided, but they were limited as well. For instance, they only supported TrueType fonts, in regular, italic, or bold. What if I wanted to use an OpenType font? What if I wanted to use a drop shadow, a glow effect, or a texture overlay? If I wanted to do any of that, I was SOL.

So, back in my XNA days, I created a custom tool for generating font sprite sheets in Photoshop, called “FontBuilder”. Basically, when you run the program, Photoshop is opened and each character is displayed on screen. You can then modify the font however you like – change the size, color, layer styles, add additional symbols, etc. When you continue running the program, it generates an evenly spaced sprite sheet for you. You can also specify multiple font sizes to build, and the program will create one sprite sheet for each size.

Configuration screen

Wait for user to edit font

Font for user to edit

Completed font (black added for visibility – normally transparent)

Build in progress

Custom font with dropshadow (gray added for visibility)

I used the FontBuilder to generate various OpenType sprite sheets for my XNA game. However, one very important thing was lost when using fonts as sprite sheets – kerning data! Being slightly OCD, kerning wasn’t something I could live without, so I later created a tool to extract kerning data from a font file.

Sadly, after all the effort I put in, my solution was still to limited. When dealing with Asian languages, or languages with extremely large character sets or possible combinations, the sprite sheet solution just falls short. If your game does not allow textual input from the user, there are acceptable solutions to this problem, but if users are allowed to type text in your game, the sprite sheets just become too large. To provide support for Korean character input, I would have to generate around 8,000 symbols (if I remember correctly). I was (and still am) residing in Korea, so Korean character support was very important to me.

Another problem with XNA is that it doesn’t provide support for IMEs. In other words, even if my font sprite sheets supported the language, there’s no way someone could type Chinese within my xna window, because it requires various popup windows to function. After a lot of work, I managed to get partial IME support, but there were quite a few glitches and shortcomings, so I started looking elsewhere, and eventually abandoned XNA altogether.