Sweet! I’ll assemble everything necessary from Jimmy’s second image above and make a pull request.Graf Zahl wrote:The BigFont as single characters looks like it's working now. So if you want to add something there, now is the time.
GZDoom localization development thread [Split]
Re: GZDoom localization development thread [Split]
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom localization development thread [Split]
I'll have to do some thorough checks if those uppercase letters don't cause any problems elsewhere.
Re: GZDoom localization development thread [Split]
Will this affect all areas - e.g. printed messages in ACS? I don't know how much this will be cared about but I guarantee that there will be loads of mods out there with HUDMessages and Print messages where people didn't pay much mind to capitalisation of their text simply because upper case and lower case ended up with the same result on screen.
- Kinsie
- Posts: 7399
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: GZDoom localization development thread [Split]
I'm pretty sure that's what Graf's worried about.Enjay wrote:Will this affect all areas - e.g. printed messages in ACS? I don't know how much this will be cared about but I guarantee that there will be loads of mods out there with HUDMessages and Print messages where people didn't pay much mind to capitalisation of their text simply because upper case and lower case ended up with the same result on screen.
Personally, I'd stick to the lower-case characters for the official GZDoom distro and leave upper-case to modders to avoid any issues caused by decade(s) of precedent.
Re: GZDoom localization development thread [Split]
1px kerning still needs to be added to that font, judging by the preview.
Re: GZDoom localization development thread [Split]
A couple of flash thoughts:
(1) I don't think anything necessarily precludes inclusion of two versions of the Doom BIGFONT, one with uppercases and one without. Keep in mind that there have always technically been two versions since Vanilla - one for the menu, and one for the intermission screen that omits uppercases! The majority of use cases of DBIGFONT have been based on this latter version of the font. In the event that this new font is indeed problematic, for legacy purposes I imagine one should still be able to set the no-uppercases font with SetFont("BigFont"), and we could designate the uppercase font as "BigUpper", or whatever. Perhaps "BigLower" would be the same as "BigFont", in order to keep a non-ambiguous moniker for the legacy font.
(1.5) (Then again, calling the "lowercase" characters as such is a misnomer - they're technically SMALLCAPS. Not that this matters much, I suppose.)
(2) If the new BIGFONT turns out to cause more visual problems than it solves, then - big ask, I know, but - why not give HudMessage a long overdue overhaul? Perhaps if a new, more efficient HudMessage function was created (perhaps with font choice built-in?), the default font used could be the new BIGFONT with uppercases, and this would theoretically leave all the legacy instances of HudMessage tied with SetFont("BigFont") alone and not cause problems.
(1) I don't think anything necessarily precludes inclusion of two versions of the Doom BIGFONT, one with uppercases and one without. Keep in mind that there have always technically been two versions since Vanilla - one for the menu, and one for the intermission screen that omits uppercases! The majority of use cases of DBIGFONT have been based on this latter version of the font. In the event that this new font is indeed problematic, for legacy purposes I imagine one should still be able to set the no-uppercases font with SetFont("BigFont"), and we could designate the uppercase font as "BigUpper", or whatever. Perhaps "BigLower" would be the same as "BigFont", in order to keep a non-ambiguous moniker for the legacy font.
(1.5) (Then again, calling the "lowercase" characters as such is a misnomer - they're technically SMALLCAPS. Not that this matters much, I suppose.)
(2) If the new BIGFONT turns out to cause more visual problems than it solves, then - big ask, I know, but - why not give HudMessage a long overdue overhaul? Perhaps if a new, more efficient HudMessage function was created (perhaps with font choice built-in?), the default font used could be the new BIGFONT with uppercases, and this would theoretically leave all the legacy instances of HudMessage tied with SetFont("BigFont") alone and not cause problems.
Re: GZDoom localization development thread [Split]
Yeah I agree that an "all or nothing" replacement of the stock Bigfont is a bad idea. The mixed case one should be opt-in.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom localization development thread [Split]
The new font will be a great asset for allowing better menu localization in Doom, because now it is possible to define text based replacements for the graphics without visual degradation.
But beyond that I'm not convinced. It will create some jarring inconsistencies on the level summary with the WILV* lumps and many mods out there do not have proper capitalization of their map names for display here anyway. For this case my suggestion would be to leave it as it was, there already is an option to set this font in MAPINFO's Gameinfo section.
For everything else: no. "BigFont" needs to remain the one without capital letters or several mods doing HUD message output with it will be negatively affected. If that new font is given a different name it should be fine. Then the mapper will have the choice.
But beyond that I'm not convinced. It will create some jarring inconsistencies on the level summary with the WILV* lumps and many mods out there do not have proper capitalization of their map names for display here anyway. For this case my suggestion would be to leave it as it was, there already is an option to set this font in MAPINFO's Gameinfo section.
For everything else: no. "BigFont" needs to remain the one without capital letters or several mods doing HUD message output with it will be negatively affected. If that new font is given a different name it should be fine. Then the mapper will have the choice.
Re: GZDoom localization development thread [Split]
So what will we do about this? Do you want me to make a version without uppercase letters at all?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom localization development thread [Split]
The end result will be that this full font will probably be named BigUpper, and BigFont will be changed to only contain the regular, now lowercase characters. If you can do that, it'd be great.
I'll be a bit busy with under-the-hood work. After transitioning the Windows backend to Unicode and allowing the Posix backend to pass full Unicode characters to EV_GUI_Char, the next big step will be to convert all text input from game data upon load and make sure that all internal text representations for everything are consistently UTF-8.
For that I need to make sure that I don't miss anything. Text lumps run through FScanner are easy: Convert them after loading, before parsing and they should be fine. For other text lumps I have to check the parsers, but I believe that the only one that may transfer text to other places is Dehacked. For binary lumps containing text there's ACS's string tables, Strife's dialogues and the file names in the resource management. Zips are gping to be tricky because I found out this morning that SLADE screws up badly when getting fed with non-ASCII file names and creating non-standard Zips that look quite a bit broken on all platforms I tested them on. The good thing about this is that it was basically impossible to load any Zips with non-ASCII file names in the first place, so there's no backwards compatiblity concerns when I declare this part UTF8-only with no handling for broken old stuff.
I'll be a bit busy with under-the-hood work. After transitioning the Windows backend to Unicode and allowing the Posix backend to pass full Unicode characters to EV_GUI_Char, the next big step will be to convert all text input from game data upon load and make sure that all internal text representations for everything are consistently UTF-8.
For that I need to make sure that I don't miss anything. Text lumps run through FScanner are easy: Convert them after loading, before parsing and they should be fine. For other text lumps I have to check the parsers, but I believe that the only one that may transfer text to other places is Dehacked. For binary lumps containing text there's ACS's string tables, Strife's dialogues and the file names in the resource management. Zips are gping to be tricky because I found out this morning that SLADE screws up badly when getting fed with non-ASCII file names and creating non-standard Zips that look quite a bit broken on all platforms I tested them on. The good thing about this is that it was basically impossible to load any Zips with non-ASCII file names in the first place, so there's no backwards compatiblity concerns when I declare this part UTF8-only with no handling for broken old stuff.
Re: GZDoom localization development thread [Split]
Gotcha. The pull request has been updated, with all the uppercase characters for Doom put into “bigupper” folders.
I take it that uppercase and lowercase won’t be possible to combine in the same string if they’re going to be put in separate folders? If they can, there’s another change I need to make.
I take it that uppercase and lowercase won’t be possible to combine in the same string if they’re going to be put in separate folders? If they can, there’s another change I need to make.
Last edited by Kostov on Fri Feb 15, 2019 9:55 am, edited 1 time in total.
- theleo_ua
- Posts: 162
- Joined: Sun Feb 07, 2016 11:38 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Ukraine
- Contact:
Re: GZDoom localization development thread [Split]
Maybe this should be discussed with slade's dev team and they can fix this in future version?Graf Zahl wrote:I found out this morning that SLADE screws up badly when getting fed with non-ASCII file names and creating non-standard Zips that look quite a bit broken on all platforms I tested them on. The good thing about this is that it was basically impossible to load any Zips with non-ASCII file names in the first place, so there's no backwards compatiblity concerns when I declare this part UTF8-only with no handling for broken old stuff.
Re: GZDoom localization development thread [Split]
I’ve made an issue on their GitHub regarding the lack of encoding support. It could be expanded so that it applies to Strife dialogs as well.theleo_ua wrote:Maybe this should be discussed with slade's dev team and they can fix this in future version?Graf Zahl wrote:I found out this morning that SLADE screws up badly when getting fed with non-ASCII file names and creating non-standard Zips that look quite a bit broken on all platforms I tested them on. The good thing about this is that it was basically impossible to load any Zips with non-ASCII file names in the first place, so there's no backwards compatiblity concerns when I declare this part UTF8-only with no handling for broken old stuff.
Re: GZDoom localization development thread [Split]
Plus, Graf has already posted a reply in their topic bringing attention to that very issue.