Oddities/contradictions re: fnt file format edge cases & fnt documentation

First of all, this section from the "Inside Playdate" document mentions that .fnt supports comments, which begin with two dashes.

image

However, this contradicts with the fact that "--" can appear as a kerning pair, in which case it isn't ignored ("--" kerning pairs work fine in the Simulator), and thus it isn't always a comment. Documentation makes no mention of this.


Similarly, a character or kerning pair and its offset are "separated by any amount of whitespace" — no mention of what happens when a kerning pair contains a whitespace character. This is especially problematic when a kerning pair ends in a whitespace character (it seems to work fine when the whitespace character is the first character in a pair, or when it is the sole character).

When a kerning pair ends in a whitespace character that is not U+0020 (ascii space), such as U+00A0 (no-break space), this often results in an error during compilation (I use Linux). It thinks this whitespace character is a separator like the tab character, and the kerning pair ends up being treated like a single character (the first character of the pair), potentially causing a compilation error about the table not having enough images, or lines with character spacing appearing after the first kerning line.
Caps seems to deal with these kerning pairs just fine, by the way.


Another thing: the Supported characters section seems outdated? .fnt fonts (and Caps too) support way more than this; it kind of seems like a remnant from back when Caps only had Basic Latin (with a few extra characters like ™) and hiragana/katakana. Even the Buttons section of the design document recommends using characters that aren't in that list.

(edit: fixed section links as some of those have apparently changed)

1 Like

Ohhh, yep, that .fnt file section is pretty out of date. :frowning: We now support all Unicode up to U+3FFFFF, and I forgot to add that you can use the U+xxxx format in the spacing and kerning tables. Looking at that code again, though.. it's converting, say, U+20 to a space and then interprets it as whitespace. Also, if I'm reading my own code right the -- this comment will be ignored line would be ignored because it doesn't have a number following the --, but since it's in the spacing section instead of the kerning section it throws an error. nm, I wasn't reading it right, it does ignore the line. But it you did something like -- 3/5/22: tweaked spacing it would misread it as a dash+dash = 3 kerning pair.

I'll fix these cases and update the docs. Thank you for for catching this! :heart:

1 Like

Neat, thanks! Though..... I believe that kinda raises another problem?
Say we have U+1F0A1: is this a kerning pair consisting of U+1F0A (Ἂ, polytonic greek) and the digit 1? Or is it a single character U+1F0A1 (🂡, ace of spades playing card)?

I think it would only be possible to have unicode codepoints as an option without this problem if the former situation (unicode codepoint + literal character) isn't allowed, instead only allowing unicode codepoints to be used if both characters in a kerning pair are always formatted that way (i.e. as U+1F0AU+0031, which would be unambiguous).

Yes, the U+xx parsing is simple, will continue as long as it sees a digit, so you have to do U+1F0AU+0031 to make that kerning pair. This seems like such a rare case I don't expect that'll cause anyone much trouble

1 Like