I wrote a pdf generation library for my Android app because the built in one would embed uncompressed images into pdf documents, giving me gargantuan file sizes! My library embedded compressed images, and it worked like a charm. That is until a man from Norway sent me an email yelling “your app outputs blank pages!” When I received it, I immediately checked the app — lo and behold, my version worked just fine… that was not a good sign!
My app’s name is Report and Run, and I started working on it as a side project for my father. Basically, he would inspect job sites and send photos ad hoc in emails and text messages from his phone, or he would return to his office to put his findings into a proper report. I wrote an Android app that took his photos, comments and annotations and outputted them in a nicely formatted pdf report. He could send this report from his phone on-site, which saved him time. I also released the app on the play store so that anyone from anywhere could use it, which is where things get interesting.
So, I had user from Norway, and his pages were blank. I requested as much information as possible about the problem, and I was lucky because he sent me a lot of screenshots and a sample report. However, that still left the question: how could mine work and his not?
- I checked his pdf in multiple pdf viewers; they all showed blank pages.
- I checked his report to see if there were images were inside it; there were.
- I checked to see if text was inside his report; there was.
- I checked to see if characters like ‘Ø’ would break my pdf generator; they did not (even though I only supported basic latin characters at that point).
- I recreated his report on my phone with images I extracted from his pdf… and mine still worked!
The difficulty with this bug was that the output was buried inside of a file format that was not meant to be inspected in its raw format. Thankfully, there is a tool called PDFXplorer that let’s you examine the document tree inside of a pdf document. With this tool, I compared my version and his version line by line to see why his was blank and mine was not. It wasn’t long before I spotted the difference: commas.
I learnt something new from this bug. In Norway and some other countries, a comma is used to mark a decimal place. So, for example, in Australia, we write “2.5” whilst in Norway they would write “2,5”. My pdf generator was using the default locale, and pdf viewers were getting commas where they expected periods. To test my theory, I switched my phone to Norwegian, and it broke, thank goodness! Once I knew what was wrong I managed to fix the bug in less than a minute.The bug fix looked like this
String buggyText = String.format(“%0.2f”);//works in some countries
String goodText = String.format(Locale.US, “%0.2f”);//works everywhere
I emailed him an update, and I updated the play store as well. There were two main takeaways. First, vocal users are very important. If this user had not taken the time to get in touch with me, I would have never known of the bug, and other potential users would have just deleted the app. Second, information is key. If the user had not sent me a sample report, I would not have been able to verify that there was a bug, and if the user had not sent me screen shots, I would not have been able to reproduce his report in my phone which ultimately led to squashing the bug!