Caps unexpectedly adding empty � glyph

SDK Bug Reports
1

Hi! I wanted to use Caps to slightly edit a third party font (with embedded image data), and noticed that re-exporting the font led to the default Ⓐ and Ⓑ etc not being displayed anymore.

These special glyphs are not included in the font itself, but the drawText() function will usually fall back to the system font to draw them, so it automatically "mixes" both fonts for you. Caps however, automatically added in some sort of default image for the � (unknown) glyph, which in turn prevented the system font from being used. This happens even if you don't make adjustments to the font in Caps.

  1. Manually removing the image in Caps before exporting did not fix it, because the empty � was still added to the .fnt file (with a width of 0).
  2. Removing the line from the .fnt file resulted in the Ⓐ and Ⓑ showing again, but broke the characters following it. (I'm not sure how the embedded data is encoded, but I expected this to work since the glyph has a width of 0, so I assumed it would not change the "offset" of the next glyph.)
  3. I eventually replaced the � with a character I don't need to display, and this fixed the issue for me.

Even if the fallback mechanism is not something you should fully rely on, it's handy and this result was quite unexpected.

tl;dr Importing and re-exporting a .fnt file in Caps (seemingly a no-op) breaks the rendering of the built-in Ⓐ, Ⓑ, :lock:, :yellow_square:, :fishing_pole_and_fish: glyphs.

1 Like
2

Same here: Opening a file I had been working on in a text editor ended up with the graphics and character order jumbled up.

Exporting with a separate .fnt file showed that the emoji arrows I used for the dpad graphics had moved down to the kerning section, so I think what has happened is somewhere when opening the file the characters are counted as unicode code units instead of characters, and it thinks ":arrow_left:" are two characters next to each other. ("⬅️".length === 2)

Edit: :fishing_pole_and_fish: seems to work though, and also consists of two code units. The difference I'm guessing is that the emoji arrows are variations of the "\u2B05" arrows ("\u2B05" + VARIATION-SELECTOR-16), which unfortunately seems much more annoying to fix.

Anyway, switching to more basic arrow characters is a good enough solution for me, but I got the idea from the documentation, so perhaps something could be done there instead if the problem is big enough.

3

Thanks for the extra info. I will make sure this is filed in our system as a bug, hopefully we can take a look at it soon!

2 Likes