Why is there a slight offset when renaming some files?

Is it just my Win10 with a 1080p screen and standard system fonts behaving strangely or is it a bug?

Some screens (green = no offset):
100%
Clipboard Image

600% zoom (green = no offset)

Test patterns:
TEST.AKKKKKKKAKKKKKKKAKKKKKKKAKKKKKKKAKKKK.1.txt
TEST.AKKKKKKKAKKKKKKKAKKKKKKKAKKKKKKKAKKKK.2.txt
TEST.JAPANESE.1.txt
TEST.JAPANESE.2.txt
TEST.Japanese.3.txt
TEST.Japanese.4.txt
TEST.JAPANESEJAPANESEJAPANESEJAPANESEJAPANESE.1.txt
TEST.JAPANESEJAPANESEJAPANESEJAPANESEJAPANESE.2.txt
TEST.KOREAN.1.txt
TEST.KOREAN.2.txt

My (?) Results:
These samples come with an offset:
TEST.JAPANESE.
TEST.JAPANESEJAPANESEJAPANESEJAPANESEJAPANESE
TEST.KOREAN

No offset with these samples:
TEST.AKKKKKKKAKKKKKKKAKKKKKKKAKKKKKKKAKKKK
TEST.Japanese
TEST.KOREAN

It's not a bug, at least not in Opus. You could argue that it is a bug in Windows. Different Windows font rendering APIs started to use slightly different kerning in one of the Windows updates. Having certain characters in the string can also trigger one API to switch kerning modes, which is quite odd. None of this is documented, of course.

The edit control used when renaming is a different piece of code (and part of Windows) to the file display that displays filenames that aren't being edited, so slight differences are entirely possible.

(We have actually done some unreleased changes to patch those APIs to make kerning consistent throughout the application, but it's pretty experimental and we want to test it for a long time before releasing it, given that the problem is almost entirely cosmetic. There are a few places where it means width calculations / line wrapping can go wrong with certain combinations of characters, though, which the API patches seem to have fixed, but those were also very rarely encounted.)

1 Like

So Windows 10 inconsistent UI elements are not alone... Good to know hehe.
I hope that Opus devs will squash it someday.

Thanks for the answer!

1 Like