Fundamental Type Support
Since unsigned char can be used interchangeably with uint8_t, I’ve updated the code to first replace all instances of unsigned char with uint8_t within the extractFont function. This ensures compatibility with both types.
Since unsigned char is a fundamental type and tends to integrate more smoothly with legacy code, I’ve chosen to use unsigned char instead of uint8_t in the Process and Create File section.
Hi @Insoft-UK
I understand the idea, but technically, unsigned char is not guaranteed to be an 8-bit type, while uint8_t is (if available), right? So I'd be inclined to use uint8_t for exporting (what is done already); what legacy code did you encounter where this was posing a problem?
I’ve come across some cases where unsigned char is used instead of uint8_t, which is why I included support for it. I understand that char isn’t guaranteed to be exactly one byte, even though it almost always is in practice. That said, I figured you might choose not to include it, since most of the existing .h files already use uint8_t consistently.
Thanks for the context. I'd leave the export with uint8_t for now, but I'm all in favour of the first replace(), if you want to amend the PR 🙏🏼