Improving how ODK Validate deals with high-dpi diplays

Hi everyone,
Not sure if this is the right place to post this, haven't seen it on GitHub but I don't feel qualified to post there (I'm not a developer).

In summary I'd like to suggest an improvement for ODK Validate, namely improving how it deals with high-dpi displays and scaling. I have a high-dpi laptop screen (3200x1800 resolution on 13 inches), running Windows 10, 64-bit, and when I use ODK Validate (1.7.0) the user interface is small with especially tiny letters. From what I've found online this is a common issue with older (java) apps, and is caused by the app telling Windows it is dpi-aware, even though it's not.

What is the general goal of the feature?
Increase user-friendliness of ODK Validate on high-dpi screens with Windows (not sure if it's also a problem for other OSs).

What are some example use cases for this feature?

What is the potential impact of the feature?
Prevent neck- and back-issues for users like me, since we don't have to put our faces 5 cm from the screen to be able to read the text :wink: I'm not sure how many users experience this right now but it might increase since high-dpi screens are becoming more common.

What can you contribute to making this feature a reality?
From what I've been able to find so far, I see three solutions:

  1. Users who experience this issue fix it themselves, but it seems like you'd need to mess with the registry which I'd prefer not to.
  2. Make ODK Validate tell Windows it's NOT dpi-aware, in which case Windows will scale the app automatically. This may give the UI a fuzzy look but at least we'll be able to read it.
  3. Make ODK Validate adjust to high-dpi screens by itself or allow users to manually increase font sizes or scaling. As I said I'm not a developer so I have no idea how easy that would be.


GItHub is for everyone! We don't check resumes or anything :smile: and the detail you provided in your post proves you are very qualified!

For ODK, GitHub is the mostly developer-centric place for issues that can be fixed/closed and the forum is the place for mostly user-centric place for mostly open-ended discussions. When in doubt, use the forum because it's more inclusive.

It sounds like you've done quite a bit of research already on a couple of solutions, which is a huge help. I've filed the issue at and I'm hoping we can have a contributor take a look at this soon.

You've already helped by filing a detailed feature request. If you want to help a bit more, you might consider editing the registry and seeing if that makes a difference. If you aren't comfortable with that, no worries!

1 Like

Thanks Yaw!

In the meantime I have found a much easier solution: upgrading to Java SE Runtime Environment 9. I was using 8, probably because the site links to a page where you can download version 8.

As described here, release 9 fixes the high-dpi scaling issue for Windows and Linux (for Mac OS it was not an issue to begin with).

Java RE 9 can be downloaded here for those who would like to upgrade as well.

Assuming both ODK Validate and ODK Briefcase run well on JRE 9, I think this fixes my issue and there would be no further need to address it :slight_smile:

1 Like

Thanks for all that great detective work, @Lieke! Seems we should update the instructions.

One thing I also wanted to mention is that in general you should really only need Validate if you're manually editing XML. Tools like or XLSForm offline automatically run Validate after converting your forms (if you want to be more technical about it, it's actually that the tools are all built on top of pyxform which itself runs Validate).

If you do need to manually edit XML, it would be great to know what you're doing that requires it so that we can look into getting some of that functionality into XLSForm.

Thanks Hélène, that is very good to know.

I was using Validate not because I manually edit XML but because the first time I tried the web-based version of the XLSForm converter it was not working, so I tried the offline one instead (this one, not Nafundi's, because it was the first one mentioned). Because this app does not check for errors I used Validate for that.

The web-based XLSForm converter probably did not work at the time because of issues with my form definition but by then I was used to the offline one combined with Validate. It works fine but is a bit of a hassle, I just tried the web-version again and am now wondering why I was making it so difficult for myself :wink:

So thanks again for the advice!