Feature Request Better Fallback system for missing characters

This one seems like a no-brainer for me, but here goes:
The current setup for missing characters currently is that a secondary text field gets automatically created on top of the original one, and a different font is used (the "fallback" font).

So for example, my "FONT1" is missing all punctuation. I just went through the process of creating a second font atlas ("FONT2") from a similar looking font with only the missing punctuation I want. Then I assigned this FONT2 as the fallback to FONT1.

BUT consider this: When we generate a font texture atlas using the tool, it reports what characters are missing. So, how about adding more options to that tool that would let us specify a fallback font and the missing HEX codes we want to add and have the result all be in the one original font atlas? Then there won't be any secondary textfields getting created and materials will also match!

 

The idea of combining glyphs from multiple fonts in the same atlas texture has been brought up a few times and something that is most certainly worth exploring.

On the other hand trying to potentially combine multiple fonts and glyphs into the same font asset, that would not really work as although the fonts might be similar in style, their face metrics would be different along with OpenType features.

Having said that, improving the Font Asset Creator to allow as you suggest to select multiple fonts where you still end up with multiple font assets but with their fallback already defined could be interesting and certainly a workflow improvement. Ie. you would pick your primary font asset and then define potential fallbacks where based on your specified list of unicode, it would use whatever is available in the primary and then search through the potential fallbacks for those missing glyphs.

Similar to the above, it would be nice to also have the Font Asset Creator be able to support Multi Atlas Texture where additional atlas textures would be used to make sure all the specified glyphs could be supported without having to use larger atlas textures.

 

@Stephan_B
Thank you for your reply.
I wouldn't go so far as to support many additional fonts. At the most Primary + Secondary (aka fallback) might be enough. I completely understand the complications you mention though.

The goal if possible in any degree, from my high-level point of view is two fold:

1. More optimal assets if it's 1 texture atlas and consequently 1 text field (no submesh)
2. Matching materials (but this may be a whole other issue I don't quite understand)

Regarding point 2, for example, this is what I ended up with recently:



My primary font is on the left and the fallback font is the exclamation mark. Maybe I went about creating the fallback atlas wrong, but in order to match the character sizing I had to set the scale of the fallback font to 1.25. That seems to have the effect of scaling the material along with it (eg: thicker outline, thicker shadow, etc)

 

One of the challenges with fonts is the lack of standards where for instance a 36 point type face could be larger or smaller than another. I have run into fonts that were as much as half the size of another font with their baseline shifted way up. Ascent and Descent lines can also vary greatly like in the case of Arial / Liberations vs. NotoSans CJK whose Ascent line is so much higher as seen below.


LiberationSans (left) - NotoSansCJK (right)

Notice how the glyphs from NotoSansCJK are slightly taller but the Ascent and Descent lines substantially different. Since text layout and alignment is driven by those metrics, this would result in top aligned text being pushed down when a character from NotoSansCJK would be added as top aligned text is position relative to the tallest ascender of the first line.

To resolve the above, you would normalize / adjust the face metrics of NotoSansCJK in the font asset inspector to match those of LiberationSans as seen below.



As per your example and without knowing what your primary font and alternative font fallback are, adjusting the scaling and metrics of the fallback is likely the only solution. This is not something that combining them would resolve as we are dealing with two fonts with varying metrics / sizes.

In terms of the outline appearing thicker on the fallback, that is something that can be addressed by making sure the Sampling Point Size to Padding ratio is the same for both font assets (if using the same source font) and most likely the same for different fonts or slightly adjusted for some font but still something that can be adjust to get the same visual appearance in terms of thickness of outline for the same material property values used on the primary.

I have made several posts about this Sampling Point Size to Padding ratio. I would suggest looking up some of those threads / posts if you need more information or to just ask here

Below is an example of the same two fonts where I used a Sampling Point Size of 90 with Padding of 9 or 10% ratio for LiberationSans but different ratios for NotoSansCJK to show you the different when an outline is applied.


Sampling Point Size (90) and Padding (9) for a Ratio of 10% for both.


Same 10% ratio for LiberationSans but only 5% for NotoSansCJK. Notice how the outline is half the thickness now.


Same 10% ratio for LiberationSans but 20% for NotoSansCJK. Notice how the outline is much thicker now.

So back to your case, I would suggest making sure the Sampling Point Size to Padding ratio is the same for your fallback. This should give you a consistent outline thickness between the two. If not, you will need to slightly increase or decrease this ratio to match your primary font asset.