Character spacing is poor

[ironss]

All character bitmaps are left-aligned: the left-most pixel is at the left-edge of the bitmap. All of the blank space (if any) is at the right-hand edge of the bitmap. Characters such as 'A', 'V' and 'Y' do not have any blank space at either edge. As a result, these characters collide with other characters with vertical left-edge ('B', 'E', '[', '|').

The code ignores the bitmap_left parameter, which indicates how much blank space there should be on the left-side of the bitmap.

Commit https://github.com/ironss/micropython-font-to-py/commit/44ce092045f228981f8511616e72da047714acdb adds code to move the generated bitmap to where it should be.

[peterhinch]

[EDIT] I have pushed an update including the bugfix and your suggested changes. I have acknowledged your contribution in the doc.

Thank you for this useful fix.

[ironss]

I have found that this introduces 2 new issues depending on the font and the character size.

• negative bitmap_left value (eg. capital J) so that the bottom of the J protrudes into the space of the preceding character.

• bitmap is wider than the advance (eg. capital K) so that the bottom leg of the K extends into the space intended for the following character.

These effects are intended to give better character spacing. This is sometime called 'kerning', but that word really means the changed character spacing between specific character-pairs, not the general spacing for a single character.

DejaVu Sans capital-J at sizes 20, 24 and 32 (and probably most other sizes) has a negative bitmap_left parameter. This means that the bottom of the J protrudes into the preceding character space. The problem is that the generated bitmap has the offending pixels on the end of the row above where they should be.

DejaVu Sans capital-K at sizes 20, 24 and 32 (probably most other sizes) has bitmap wider than left+advance. The bottom leg of the K protrudes into the next character space. This problem is that the generated bitmap has the offending pixels on the start of the next row down.

There are three alternatives:

• Handle this properly. Each character will need to have additional parameters (bitmap_left and advance), drawing character strings become tricky because we are not simply concatenating bitmaps, but have to composite them, and probably more. All do-able, but probably not worth the effort.

• Drop the offending pixels. This keeps the bitmap the correct size, but the character has the wrong shape.

• Adjust the shape of the character in some other way.

• Increase the width of the bitmap so avoid the protrusion into the previous or next character in the string. Character spacing will not be ideal, but is acceptable (to me).

I suggest the last option.

I have a fix for the negative-bitmap_left (https://github.com/ironss/micropython-font-to-py/commit/b572029bea7d08687710adf7b0cadcf6c76ad575) but am still working on the bitmap-wider-than-advance.

I suspect that the whole character-width calculation (around line 335--340) will need to change.

To see these effects, add some debug output (https://github.com/ironss/micropython-font-to-py/commit/6606f31b069c8c92b0fcdd9f0803d1d4b9bf77d8, where each occurrence of command-line option -v increases debug verbosity), then run

• python font_to_py.py /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf 32 MyFont_32.py -vv

and look at characters J and K.

[peterhinch]

The last option sounds simplest.

[ironss]

I created a new issue, and implemented a fix https://github.com/ironss/micropython-font-to-py/commit/e73da4cbbd669148d486b0717c793a5415ce32a2 that creates correct bitmaps for (at least) DejaVu San J, K and R at various sizes.