Text height is not enough in some cases

[annenveritas]

The height of rows in the Tree View doesn't seem to be high enough to display tall symbols with top combining diacritics and low symbols with bottom combining diacritics. For example, letter Å with acute on top of it, Ǻ, doesn't seem to fit the line. Another example would be an Arabic /ri/ syllable (a /r/ letter with bottom /i/ diacritic): رِ. The same seems to apply to the Tag Editor window. Here are some screenshots: https://imgur.com/a/4lqIZzk.

I'm not sure if this is any easy to change, especially in case of the Tag Editor, but still I think it's important to point out that such problem exists and might mean a lot to some users. Though, since these things are likely pretty rare in terms of what most users would want to store in NBT format, I think the changes to text's height would be better off conditional: if there's any symbol like that to be displayed, set the height a bit higher, but otherwise keep the height default. Or maybe changing the hardcoded height just to cover for these marginal cases wouldn't look too bad on the more usual latin-script input - in this case, maybe just changing the hardcoded one would be nice.

[tryashtar]

Thanks for the report, most likely I'm not going to bother fixing this because I don't want the tree to become less compact (I'm pretty sure all rows have to be the same height), and basically all NBT in practice is ASCII

[annenveritas]

I don't want the tree to become less compact (I'm pretty sure all rows have to be the same height), and basically all NBT in practice is ASCII

Oh, by "the changes to the text's height would be better off conditional" I meant changing the lines' height for the whole tree if there's any symbol like that on screen [to prevent affecting the average user's experience] - not just for that specific line (which likely would be pretty difficult to do with the way it's currently implemented). And by the way, the reason I personally switched to NBT from XML, is the Unicode support and the ability to store arbitrary things (for example, any natural language text) in such clear hierarchical format - so it's not something that, in practice, no one could ever want as a feature.

[tryashtar]

Don't worry, unicode support will stay in for sure. But changing the height to match which strings are on-screen is pretty low priority for me now