FONT_NUMBER_* and alpha characters

Yes, if you're using FONT_SYSTEM_NUMBER_* they only have the numeric characters as the name suggests. Use the other fonts that don't have NUMBER in their name.

Yeah, the history here is that Garmin devices have traditionally had low amounts of memory (and still do), so the fonts with the biggest characters (FONT_NUMBER_*) also have a restricted character set, in order to save memory. (Since the use case for large characters is to display data field values, and data field values are typically numbers, it makes sense that the "big fonts" only support numbers. Another obvious use case for big numbers would be the numerals in a watchface - this is perhaps more compelling than the data field value use case, although many native watchfaces obviously use custom fonts)

Typically, the following characters are supported by numerical fonts:

#%+-./0123456789:°

(This used to be part of the developer documentation, but it's been removed). The last time I checked (years ago), watches supported spaces in numerical fonts, but Edge devices did not.

Notes for numerical fonts and simple data fields:

At least in the past, if you returned a String in compute(), the device would intelligently decide whether to use (big) numerical fonts or (small) non-numerical fonts, based on the contents of your string. At least at one point (years ago), I found that anything other than the following characters would trigger the usage of the smaller non-numerical fonts in a simple data field:

0123456789:.

In this context, spaces are not allowed. If you restricted your simple data field's string returned by compute() to the above characters (with no spaces), then a big numerical font would be used.

However, more recently, there have been many bugs associated with simple data fields unexpectedly rendering text that looks too small. At one point, returning a String in compute() would always cause non-numerical fonts to be used, even if the string only had "numerical" characters. (This may still be the status quo for the latest devices.)

People have also noticed that even when a Numeric type (Number/Long/Float/Double) was returned in compute(), devices would sometimes use non-numerical fonts, but that bug may have been fixed.