Weird behaviour with right alignment (setTextDatum(TR_DATUM);) of ITALIC smoothfont

[Rollmops67]

Hello !

I just created a smoothfont based on a ttf font representing italic letters and numbers in a 7 segment LED or LCD fashion to simulate an old school digital clock.
( with the Processing IDE and using this file to hexadecimal converter :https://tomeko.net/online_tools/file_to_hex.php?lang=en )

No problem with that it's not the first smoothfont I create.
I want to show the time like this : "12:35" on a SSD1963 based display.
So I created a string to display the time, and it shows nicely.
The string is right aligned with setTextDatum(TR_DATUM); , and since the characters all have the same width, the distance between digits is always the same (for example, if the minute changes from 20 to 21 all digits remain at the same place), like on a real digital clock.
This is OK, but I noticed a weird phenomenon : when the minute goes from 4 to 5 (for example 24 >> 25), the whole time string shifts several pixels to the right. And when the minute goes from 6 to 7, the whole string shifts the same amount back to the left.
It didn't take long to find the reason : numbers 5 and 6 are the only ones without the right upper segment "on", and the shift of the string depends on the manner the right alignment works.
It looks like the alignment depends on where the the number ends.

With an images it will be simpler to understand :

The white ligns show where the right alignment is done, the little blue arrow shows the difference.
I also noticed that when a another number of the string changes (for example minutes going from 49 to 50 or hours from 16 to 17) there is no shift within the string.

The quick fix is to detect if the right number of the minutes is a 5 or a 6, and in this case change the x position of the string, so it's not really a big issue.
But I wanted to report it, there is maybe a simple fix for this. (or not)

Aniway thank you again Bodmer for your fantastic TFT_eSPI librairy !

Regards from France, Roland

[Bodmer]

The problem occurs because the font is a proportional format in the vlw file and there is no fixed spacing flag in the font file. The library uses the bitmap width to work out the bounding box because this can be larger than the character "x" advance in the case of italics. Example:

So your solution is probably the best without hacking the library.