However, ILI9341 does currently implement 2 index ranges, even though pretty much all the published font files have only one.
The second index range is meant to allow any continuous subset of the ISO8859-1 characters to be encoded. For example, you might start with 192 and end at 255 to get all the letters with accents. Or maybe start at 161 if you also want to include the special symbols, like the upside down exclamation point. Or maybe use just 224-255 if you only need lowercase letters with accents. The idea is to make publishing a font easy with two continuous ranges, for ASCII and ISO8859-1.
This 2nd index works the same way as the main one. You fill in the index2_first & index2_last fields with the first and last values. Then just add the encoded bitmaps onto the end of the big data array.
In other words, if you're encoding a font and you want to include chars 33 to 127 and 192 to 255, when you finish 127, just start making the bit data for 192 and add it right onto the end of the data array, and add their index positions within the big array onto the index list array. ILI9341 will "know" that char 192's data comes immediately after 127's data because you put 127 into the index1_last field and 192 into the index2_first field.
Here's the code in drawFontChar which the logic.
Code:
if (c >= font->index1_first && c <= font->index1_last) {
bitoffset = c - font->index1_first;
bitoffset *= font->bits_index;
} else if (c >= font->index2_first && c <= font->index2_last) {
bitoffset = c - font->index2_first + font->index1_last - font->index1_first + 1;
bitoffset *= font->bits_index;
} else if (font->unicode) {
return; // TODO: implement sparse unicode
} else {
return;
}
Here you can also see the unimplemented "sparse unicode", which was meant to allow encoding higher than 255. The idea was a 3rd array of unicode values & bit index numbers. The intention was to someday add code to do a binary search of that list. If the unicode number could be found, then then "bitoffset" for that char and used to get the bits from the index list, the same as if it has been found in the first 2 ranges. So from an encoding point of view, you could choose any sparse collection of greater-than-255 chars and just tack them onto the big bit-encoded data array.
Of course, the other necessary part never did was UTF8 parsing of the strings. But that's pretty easy and the code already exists in the USB keyboard. If you're really going to add support for unicode chars, please ping me when you're using the 2nd index range. At the very least I can update ILI9341_t3 to parse UTF8 so people can conveniently print those 161-255 chars.
If that works out and there's interest in chars beyond 255, I can also work on the missing sparse unicode stuff. But first let's focus on just getting up to 255 supported well with UTF8 strings.
Can you try to make a font file using the 2nd index and fill it with at least the accent chars 192-255? That would really help me to add and test the UTF8 support.