Concerning the double-space issue, I did quite a bit of research trying to find a fix for that. I haven't been able to find a solution as yet, but I can confirm that this isn't caused by any of the three font files (FontB0000.txp, fontB.fnt and fontB.ftd). It doesn't matter how any of these files are altered, spaces always remain twice as wide as we want them.
I can't figure out what fontB.ftd does; nulling the file (filling the file with zeros) corrupts the graphics a bit, but it's obvious spaces are unchanged.
The fontB.fnt file contains the font-grid mappings for the characters and nothing else. This can be easily edited with the toolkit, and while the third and fourth bytes would appear to correspond with character #0 (which +32 corresponds to ASCII space in hex-editors and the toolkit), this mapping is always ignored by the game. The game literally does not have or use a space character.
What must happen appears to be this: when the game is parsing text, if it encounters a &32 in a string the game just skips drawing anything and moves the draw-cursor forward 40 pixels (the width of a full-sized glyph in the font). This means the value could be hard-coded into the binary as part of the game's actual program code which means it's going to be incredibly difficult to locate.
I also noticed that there was at least one (may be more) case of there not being enough space in the EBOOT file for some bits of English text. An example is the "Insert/Replace" text that appears when arranging units. There's just enough available bytes to have the word "Insert" and two extra bytes for the button image that appears before it, but there's no space for a "00" null termination, resulting in the game considering the next part "Replace" as part of the same piece of text.
Since the text in the EBOOT must be pointered, it should be possible (if the pointer is located, and 1 subtracted from it) to shunt the problem text one byte backwards in the file making room for the null terminator.
Both problems are going to be tough to solve, it's difficult to say whether either are realistically possible either, but I'll persevere for the time being (mainly on the space issue; if I can sort this out not only would everything look nicer, but there should be less cases of text overflowing the boxes or screen) just in case I make some kind of breakthrough.