One of the folks who helped me test the Catalog version of Generations has an account user name of "LDBR_art".
When displaying their score on the leader board view, his user name was rendered as LDBRart, with "art" italicized and no underscore. I believe this should only occur for a string such as "LDBR_art_" with a leading and trailing underscore around the text to make italic.
I worked around this by defining the kVariantItalic (and kVariantBold just in case) variant to all be the same font as kVariantNormal as I didn't have an italic variation of the font (so it was falling back to Asheville), but this has the side effect of displaying the user's name in the game as "LDBRart".
Not a huge deal, but not how I think its intended to work.
Workaround is to use a double underscore to get a single underscore. It's annoying. But at least if you have some text you know shouldn't contain styles, like a userid, you can escape it to be sure.
Escaping styling characters
To draw an asterisk or underscore, use a double-asterisk or double-underscore. Styles may not be nested, but double-characters can be used inside of a styled portion of text.
Ah, thanks for that. I'll gsub them in there to display the name correctly.
I do think this is still a bug with the underlying markdown processor, though. The string in question does not have the italicized substring wrapped in underscores. For that same section of the documentation:
To draw italic text, surround the italic portion of text with underscores
Any time you are displaying text that you don't control, it probably makes more sense to use playdate.graphics.font:drawText() or playdate.graphics.font:drawTextAligned(), as these methods do not support inline bold and italic styling and will instead print the underscore and asterisk characters normally.
In our formatting system (which is not markdown), an underscore will render text as italic until the next underscore character is hit, so that is expected behavior (maybe the docs need an update, but normally you should enclose italic text in two underscores... perhaps we will enforce that in the future).
However, even if the parser did require a closing underscore a user could easily have a name that contains two underscores so you'd potentially run into the same issue. So yeah, just use the font-based drawing calls instead. As a bonus they're also faster!