Closed dwatteau closed 2 years ago
So, looking at the 98.LFL file after its modification, it appears that the width table (at offset 0x08) is corrupted.
In the original file:
Character width table: 4, 8, 6, 8, 6, 0, 0 [...]
after the scummfont
changes:
Character width table: 8, 8, 8, 8, 8, 8, 8 [...] (all 8s)
PR #48 was merged to work around this.
Basically, the following line is maybe wrong:
…in that some image editors are free to reorder/simplify the palette, but the code appears not to be ready for this.
So, we just reject any file with a modified palette, for now (GIMP and old MS Paint releases are known to leave it as-is, as long as you work from the original BMP file).
Making ScummFont even more strict is not really nice for users, but silently corrupting the game resources is worse.
ScummFont probably needs to be rewritten to either have a much more robust BMP implementation, or maybe a much better format than BMP (BMP is a bit like CSV… it seems so simple that you may think you should make your own encoder/decoder, but you really shouldn't). But that's not for now.
Tested with some games with V1 fonts, such as INDY3 PC VGA.
If you export a V1 font to .bmp, then modify it, and import it back to to the game, the new font is corrupted (in the game and in the new exported bitmap):
The corruption problem seems to be located somewhere in the
saveFont()
function.Original
scummfont.exe
also has this bug (but then you need to deal with the-new
file when reproducing the use-case above).