Basically, when editing an Indy3/Loom font with some image editors (such as Preview.app and then Netpbm), scummfont would get lost in trying to detect the variable-width of each character:
If my diagnosis is right, this check is not very reliable, because some image editors will just completely reorder the palette (and sometimes change some colors when going back to 8 bpp), making this test wrong, and then corrupting the whole font.
So, if ScummFont currently expects the palette to remain unchanged, then we need to make sure that it's the case. Hence this PR.
It's getting quite cumbersome to produce a BMP file that ScummFont will accept, but I don't really have any other quick option at the moment. We should probably use a better BMP implementation, or a better format. But doing so means that most of ScummFont would need to be rewritten, so it's not going to happen now.
Issue #15.
Basically, when editing an Indy3/Loom font with some image editors (such as Preview.app and then Netpbm),
scummfontwould get lost in trying to detect the variable-width of each character:https://github.com/dwatteau/scummtr/blob/f067b2f5235d0a1c9dfcfb658b37942e4b4e5e5a/src/ScummFont/scummfont.cpp#L400
If my diagnosis is right, this check is not very reliable, because some image editors will just completely reorder the palette (and sometimes change some colors when going back to 8 bpp), making this test wrong, and then corrupting the whole font.
So, if ScummFont currently expects the palette to remain unchanged, then we need to make sure that it's the case. Hence this PR.
It's getting quite cumbersome to produce a BMP file that ScummFont will accept, but I don't really have any other quick option at the moment. We should probably use a better BMP implementation, or a better format. But doing so means that most of ScummFont would need to be rewritten, so it's not going to happen now.