Add DynamicFont support to localization remap

[vitorbalbio]

Describe the project you are working on: https://twitter.com/ZeroPointGame

Describe the problem or limitation you are having in your project: The build-in localization system don't have support to remap Font Data .ttf files only the bitmap font files making it not useful to use Remap with dynamic fonts.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: Add ttf to the list of remap assets.

If this enhancement will not be used often, can it be worked around with a few lines of script?: will be used in any localized project.

Is there a reason why this should be core and not an add-on in the asset library?: It's a core feature

[Calinou]

Out of curiosity, why not use DynamicFont's fallback system? You can load a DynamicFont as a fallback of another DynamicFont, which lets you specify as many fallback fonts as you want.

This way, you can use a fancy-looking font for Latin-1 characters and use a simpler, but more universal font for CJK languages.

[vitorbalbio]

Out of curiosity, why not use DynamicFont's fallback system? You can load a DynamicFont as a fallback of another DynamicFont, which lets you specify as many fallback fonts as you want.

This way, you can use a fancy-looking font for Latin-1 characters and use a simpler, but more universal font for CJK languages.

Thanks for your suggestion Caillou. Looks like it works as you pointed. That said there's no point in not have Dynamic Fonts as a remap asset since it seems to be the most straightforward way to do it. Otherwise you need to setup two or more fonts for every label in the project.

[Calinou]

Otherwise you need to setup two or more fonts for every label in the project.

You can use Themes to reuse theming elements across your GUI. Define a Theme resource in your root Control node and it will apply to child Control nodes automatically. You can set a default font in the theme resource with the fallback fonts you need.

To make the theme visible in instanced scenes in the editor, you can save the theme resource to a .tres file and apply it to every root Control node in your instanced scenes.

[vitorbalbio]

That's not a good way because i need to setup and save in the project one theme per font size and option (with/without shadow...). Also it do not work with labels that need unique fonts because they set dynamically the text size (like Unity best fit option).

[Calinou]

Closing, as the need described in OP is already addressed by the DynamicFont fallback system.

[vitorbalbio]

Closing, as the need described in OP is already addressed by the DynamicFont fallback system.

You pointed a workaround! It's not the same of the reported nor there's any point in not have it as proposed since it's already implemented for mostly of the resources available today. Please consider my humble request and keep it opened so someone can take a look on it on future at least. ☹️

[Calinou]

You pointed a workaround! It's not the same of the reported nor there's any point in not have it as proposed since it's already implemented for mostly of the resources available today. Please consider my humble request and keep it opened so someone can take a look on it on future at least. :frowning_face:

We only support features if there's a valid use case for them. For all intents and purposes, I can't see an use case for remapping DynamicFonts depending on the current language. The fallback system is better suited for internationalization purposes, since it will also work in cases where the game's language doesn't match the effective text language. For example, this can happen when you display chat with CJK or Cyrillic characters in a multiplayer game with English clients.

Also, we consider that if a workaround is simple enough and documented, then it may eliminate the need to implement new features entirely. This ensures the engine's codebase remains at a manageable size.

[vitorbalbio]

We only support features if there's a valid use case for them. For all intents and purposes, I can't see an use case for remapping DynamicFonts depending on the current language.

My valid use case is my own project and the way i think it's better to implement there. https://twitter.com/ZeroPointGame. Also it's already done fpr Bitmap Fonts and mostly of the others Resource data. If you don't agree that it's not the best way to do, it yet need to be implemented because consistency for what is expected to work. Mostly of the Resources have it, Bitmap Fonts Have it. Dynamic Fonts don't. Here's the full list:

Also, we consider that if a workaround is simple enough and documented, then it may eliminate the need to implement new features entirely. This ensures the engine's codebase remains at a manageable size.

This could be said for mostly of the proposals here. But they are not closed. Also it's not like you will add a new lib to do it.

What i don't get is how in a open project one single guy can take the decision of close a proposal about something without even give other devs the chance of evaluate it. My proposal fills all requirements to be here yet you think it's not good and because your opnion and you closed it because you can. Please don't do this.

Best Regards Vitor

[Calinou]

@vitorbalbio Feel free to open a pull request to change this, but it's not as easy as adding *.ttf and *.otf to a filter because the list is generated dynamically.

It seems there's a macro to register those resource extrensions: https://github.com/godotengine/godot/blob/5525cd85c60455b0bb9716bbef0ad2ad8111d752/modules/stb_vorbis/audio_stream_ogg_vorbis.h#L75

However, this macro is only used for internal Godot resources, not those generated by other software:

[vitorbalbio]

@vitorbalbio Feel free to open a pull request to change this, but it's not as easy as adding *.ttf and *.otf to a filter because the list is generated dynamically.

No i will not. I'm not a C++ programmer and i don't need to be! I'm a user of the engine and i made a user proposal that fills any requirement to be here. I just want to keep it open so one programmer (more clever than me) can at least consider it. What are you saying is that i can't make any proposal if i can't implement it. It's absurd. There's thousand of proposals here from people that have not the knowledge to implement it.

[Calinou]

After doing some research, it turns out there's already an issue open about this on the main Godot repository: https://github.com/godotengine/godot/issues/17640

The good news is that you can already define fallbacks in the default project font setting :slightly_smiling_face:

1. Go to the Inspector and create a DynamicFont resource by clicking the New Resource button (the one with a green "plus" symbol).
2. Load a TTF/OTF file into the main font slot.
3. Unfold the Fallbacks section and load a TTF/OTF file into the first fallback slot.
4. Click the floppy disk icon at the top of the inspector, choose Save As… and save a .tres file for the DynamicFont resource.
5. Open the Project Settings and set Gui > Theme > Custom Font to the path of the DynamicFont resource you just saved.
6. Restart the editor. This is the final result:

Minimal reproduction project: test_default_dynamicfont_fallback.zip

[vitorbalbio]

I'm aware of the fallback system, you have been talking about it since the start and I'm using it as a Workaround. The point is i don't think it's the best solution (and others also as you pointed https://github.com/godotengine/godot/issues/17640 ) because:

1) Mostly of the other resources can be overwrited using the localization Remap Resource system. There's no point on this do not have from a user perspective. 2) If you have 100 labels in your project you need to setup 100 x n fallback fonts.

It's a valid proposal, i have no idea why are you closing this proposal (That is already a reported Open Bug).

[Calinou]

1. Mostly of the other resources can be overwrited using the localization Remap Resource system. There's no point on this do not have from a user perspective.

If it encourages bad practice, then supporting it might not be a good idea.

2. If you have 100 labels in your project you need to setup 100 x n fallback fonts.

This is why I mentioned the custom font project setting :slightly_smiling_face:

It's a valid proposal, i have no idea why are you closing this proposal (That is already a reported Open Bug).

If it's a bug, there's no reason to have a duplicate proposal for it.

[vitorbalbio]

If it encourages bad practice, then supporting it might not be a good idea.

I disagree. It's not bad practice. It's the best workflow. But you seem to ignore others opinion.

I will not insist on this. I'm very disappointed with this way of handle a community open project. Best Regards.

[akien-mga]

It's already possible to remap DynamicFont, here's a project that does it: DynamicFontRemap.zip

DynamicFont is a Resource type like any other, so you can save it as a Resource file (.tres or .res) and use that in the translation remappings.

Remapping TTF files cannot be done as those are not imported Godot Resources - they're used via DynamicFontData, but they're not imported. It's different for e.g. PNG or OGG - it looks like you're remapping the PNG or OGG file directly, but you're actually remapping the Godot-specific proprietary texture or sample format imported in .import/.

So there's indeed no need to implement anything extra, but maybe the documentation could be improved to show how both fallback fonts and resource remapping can be used for localization.

[vitorbalbio]

Hi @akien-mga Thanks for your time. I really appreciated your sample. 😉 This is the closest of a proper solution someone posted here but it's yet not a real replacement for a proper Dynamic Font remap because you would need to create a resource file in your project for each font size + Outline Size + Outline Color combination used in the project.

Remapping TTF files cannot be done as those are not imported Godot Resources - they're used via DynamicFontData, but they're not imported. It's different for e.g. PNG or OGG - it looks like you're remapping the PNG or OGG file directly, but you're actually remapping the Godot-specific proprietary texture or sample format imported in .import/.

I can't argument about why it can't be done since i have no idea how it's done in Godot. What i can say is only about the user experience of do not have it. It looks very very strange you can remap mostly of the file formats used (included the .font) but you can't do it with a .ttf file. Even more if it would enable the best possible workflow for localization.

So there's indeed no need to implement anything extra, but maybe the documentation could be improved to show how both fallback fonts and resource remapping can be used for localization.

I will keep my position that it's not yet a proper replacement to a much better workflow remapping .ttf fonts but i will not insist in keep it opened and i will follow the development in the bug report.

Thanks for you time @akien-mga. 😊