New Adventures in Software by Dan Dyer

I haven’t seen this problem described anywhere else, let alone solved, so this post might prove useful to some desperate future Google searcher.

A couple of weeks ago I updated Rectangular Video Poker to support Honeycomb devices. In doing so I encountered a bizarre bug. The letter ‘J’ refused to display in one particular TextView. Neither the upper case or lower case variant would show, just a gap where the letter should appear. Every other letter in the alphabet displayed correctly. The problem occurred on the 10.1″ Galaxy Tab but not on the Honeycomb emulator or the two HTC phones that I tried.

The problematic TextView had a large font size (86dp) set for xlarge screens because it is used as a banner that displays the win/lose message at the end of a hand. Eventually I discovered that if I dropped the font size to 79dp the letter ‘J’ would reappear. In the absence of any explanation for this odd behaviour, making the text slightly smaller seemed to be a reasonable workaround. Why was ‘J’ the only letter affected? My best guess is because, in the default Droid Sans font, it is taller than all of the other letters. Unusually, the upper case ‘J’ descends below the baseline. The lower case variant is also taller than all other letters.

With an adequate workaround in place I ignored the issue until the other day when I encountered the same problem porting a different app to Honeycomb. This app uses a large TextView to display a number. The font size is even bigger (a scarcely sensible 142dp) and consequently none of the digits displayed. Again, the problem only manifested itself on the Galaxy Tab.

In this case reducing the font size wasn’t really an option (if anything I want to make it bigger to occupy more of the Tab’s very large screen). I did however establish that I would have to lower the size to 101dp to make the text reappear.

I couldn’t find any references to this issue anywhere online (maybe other developers aren’t as fond of massive text as I am). Eventually, due to lack of better ideas, I speculatively disabled hardware acceleration for the activity in question. Surprisingly this solved the problem. I had been following the advice given at the Android Developer Lab to turn on hardware acceleration unless you have a good reason not to, but I hadn’t realised it was the source of my problem because I hadn’t first tested the app without acceleration.

This is the second scenario I’ve discovered in which I have needed to disable hardware acceleration for an activity. It’s also necessary when you have a WebView with a transparent background.