Consider per-language variable line height
Opened this issue · 13 comments
Currently there is a bit of an issue where characters "collide" into eachother between lines of text, making text boxes slightly harder to read and overall less appealing. Examples:
This is particularly evident in languages with additional diacritics.
Dicey Dungeons had a fairly robust customization setup for how text is displayed on a per-language basis - I don't imagine it's necessary (or possible) to implement a similarly big measure, but having variable line height would fix this issue.
(As a former localization QA tester... I would advise against this 😅 Having the UI structure change on a language basis often leads to re-testing each single line in each single language (possibly at each single update).
Maybe all languages could be tweaked in order to add a single pixel line gap in all languages, and only if it's clear it will not create any issue.
Otherwise I would just pretend this is an intentional "retro" choice, mimicking the broken aesthetic of the time and just back away whistling 😄)
Honestly, I'd quite like to do this, and I don't expect it would cause any serious issues. There was a discord discussion about it back at the end of November that did highlight some potential issues, probably the most serious of which is that it would break ASCII art in custom levels. (As for adherence to the 8x8 restriction of the original game; personally that's not that important to me - VVVVVV doesn't actually adhere to strict C64 restrictions anyway)
But I reckon it should be safe to implement this with the following conditions:
- Only in dialogue boxes, no other situations (like e.g. the script editor)
- Only in the base game, not in custom levels
- Only in languages that use the Space Station font
Some screenshots of how it looks:
This is really a pretty minor change that's unlikely to cause any problems. I think we should go ahead and do it for 2.4?
I'm gonna vote for "not for 2.4.0" honestly, sorry! We're already making big last-minute changes, I feel like we should put our energy into making sure the Arabic localization is as stable as it can get, since that is much less tried and tested - this would have its own share of possible unexpected breakages, and it wouldn't be a 1-line change. I want to avoid situations like the Nicalis Japanese version because we changed something in one part of the code but not in another:
I put a lot of time and effort into both translations and would support making them more readable (this is, in a way, an accessibility feature after all) on launch, rather than later - and Terry's plan sounds relatively foolproof?
If we're worried about misaligned text boxes covering up Viridian's face - I would argue that's a reasonable tradeoff that can wait till a later patch.
I can volunteer for extra testing!
I put a lot of time and effort into both translations
You're saying that to someone who put a lot of time and effort into his own, and the whole translation system in the first place...
We could do an "I'll see what I can do", but again, it would not be a 1-line change, the code will need to be reviewed on a technical level, it will need to be tested, and I'm worried that takes away from the limited time we have for also programming, reviewing and testing the entire Arabic translation, so it doesn't have more serious issues, like this:
As far as I've seen, this problem wasn't worse than "text boxes slightly harder to read and overall less appealing" (in two languages, according to one person). If I had to choose between fixing that and fixing "everyone can see that technical work is completely rushed and broken", I'd prioritize the latter. Maybe it'll turn out a week is plenty of time for QA-ing the entirity of the Arabic changes, and we can also easily implement and QA this on top? But I don't know yet, it's a tight deadline.
Well, it does seem like Terry got something done already, I dunno if it's a pull request or anything yet but if there's a playable build I'd be happy to help with the QA. 😇
Those screenshots are just mockups made in an image editor - the textboxes were stretched out manually.
This is something I'd be willing to backport to the 2.4 series, so we don't need to rush this out - text rendering always has weird caveats with any change but it would definitely be nice to have everything working correctly without waiting for 2.5.
Yeah I agree with that - it'd be a shame for this to have to wait until 2.5, so I think it'd be nice for a 2.4.1. (onetruepurple is saying "on launch, rather than later", but doing it for 2.4.0 while we're also doing Arabic is what I'm worried about)
Ok, that's very reasonable! Let's focus on the Arabic localisation project for now, and look about doing this once that settles.
Just reposting here what I said on the VVVVVV Discord.
I don't think the line height/gap should be variable, and I don't think it should be configurable per-language, simply because it definitely should be configurable per-level (as some text in levels expect no gap), and it gets conceptually complicated to have it both configurable per-language and per-level.
It's simplest to just have it be configurable per-level.
Just reposting here what I said on the VVVVVV Discord.
I don't think the line height/gap should be variable, and I don't think it should be configurable per-language, simply because it definitely should be configurable per-level (as some text in levels expect no gap), and it gets conceptually complicated to have it both configurable per-language and per-level.
It's simplest to just have it be configurable per-level.
Agreed!
I would not object to the following addition to this pull request - #1124
- Add a linegap meta tag to all new level files created in 2.4.1, which defaults to 1
- If an older level doesn't have the tag, just use 0
Hmmm... I'm not sure it should default to 1 for new levels, I feel like it should be a deliberate thing to enable. Trying to avoid people thinking it's no longer possible to do certain things in textboxes, going "how do I go back to the way it was" and maybe then figuring out you have to stick to an old version of the game. And it'd be confusing when a level you created a month ago doesn't do it and a level you created yesterday does, and you did nothing to cause it.
Personally I'd rather see a few more levels stick to the old spacing because the authors didn't know they could now increase it, than having level authors have problems because the spacing increase breaks their plans.
Otherwise agreed!