I encountered a really, really specific bug when testing localizations. See here: https://streamable.com/x9ncxb

One of the characters in this line gets scrambled at 0:04, as if it's pulling the wrong glyph from an atlas or something. This was recorded with Arial as the font. Bizarrely, this only seems to happen in Japanese, and with specific spacing. As you can see, the line renders correctly when I drag the RectTransform around, and it only seems to break at a specific size. I'm guessing it has something to do with either the inline font switch, or word wrap, or both.

If you want to test it yourself, you can copy-paste this line in Japanese: 10進数の「2」はバイナリで<font=monospace>10</font>と表示するんや。

My "monospace" font is mapped to SourceCodePro-Medium: https://fonts.google.com/specimen/Source+Code+Pro

I think that OnFontTextureRebuilt() is being invoked before the new font is actually added to the list of fonts being used by the mesh. Please help me test this by doing the following...

Go to the method "RebuildTextInfo()" in SuperTextMesh.cs and move this code...

if(!allFonts.Contains(Rebuild_font))
{              
    allFonts.Add(Rebuild_font);                 
}

to be directly below this line, earlier in the same for loop:

Rebuild_font = Rebuild_info.fontData != null ? Rebuild_info.fontData.font : font;

I think this should fix it, now STM will be aware of the new font before the first character in it is actually called, so it should be able to rebuild at the right time. If this works, I'll be sure the next update includes this!

Hmm, didn't quite work. It picked a different glyph this time, though: https://streamable.com/wd1k8e

And to be clear, the 

if (!allFonts.Contains(Rebuild_font))                
{ //if this font is not listed yet                 
    allFonts.Add(Rebuild_font);            
}

is currently on line 3435.

Hmm okay, then if it's not that, please try...

Inside of "OnFontTextureRebuilt()", change this line:

if(textMesh != null && hyphenedText.Length > 0 && allFonts.Contains(changedFont))

to this:

if(textMesh != null && hyphenedText.Length > 0)

This is a bit more inefficient, as it'll cause every Super Text Mesh object in a scene to rebuild when any font texture rebuilds, but it should force a rebuild no matter what and let us know for sure if that's causing the issue or not.

Also, I'm curious about the import settings of the Japanese font. Is it marked as dynamic or static? (unicode)

This time it skipped the character entirely (but you can still see the white space where the character would have been): https://streamable.com/ufxc6y

The font is set to Dynamic. But I think you can reproduce this with the stock Arial that comes with Unity, because that's what I did for my first recording.

Okay yes, I'm now messing with this myself in Unity (sorry, I really thought it was just a font texture thing...) and I can now see it has something to do with the cutoff point... dragging the bounds causes the "de" right before the font change to disappear with certain line widths... going to be looking for the fix now, it may be some of the code I wrote that specifically handles linebreaks for japanese characters.

Replying immediately, because I think that you may get the result you want right away by using the monospace numerals from japanese without any problems (０１２３...) but I want to solve this for the way you're doing it, too. It looks like I haven't included these monospace numbers in the japanese linebreak rules either, so I'll make sure to add those, too

Okay, I've got a solution!!

I'm going to just email you an updated SuperTextMesh.cs since I ended up introducing a new variable and that'd be a bit annoying to manually replace. Lemme know if it works!

Replying immediately, because I think that you may get the result you want right away by using the monospace numerals from japanese without any problems (０１２３...)

Oh! Hey, you're right. That does solve it. But yeah, it's worth solving for the other characters too.

The text in the first post is what I got from my translator, but I don't know if the half-width numerals were a stylistic choice or just an error (I'll ask him).