kerning is ignored.

[Yardie-]

Hi again I am just revisiting your code and it seems that the kerning f the fonts is not included. Is this too big a thing to tackle.

It is actually one of the most important parts of using a ttf font rather than just creating bitmaps and sticking them together this is what i am after.

[k-omura]

Thank you again. I think it is possible to implement kerning. Currently, I'm working on implementing output to the framebuffer instead of direct output to the display. I think it will be possible to implement it in the framebuffer method.

It is assumed that the kerning width is read from ttf, but I would like to find out where the value is.

As another matter, I'm thinking of deleting the code that draws directly on the display with the change to the frame buffer method. I think this is simpler and more versatile. If you have any opinions on this point, I would love to hear from you!

Thank you!

[k-omura]

The implementation of kerning is completed in the framebuffer format. I would like to commit after confirming the operation a little in the future.

And, the front-end commands have changed a little, so I will prepare sample code and documents!

Below is example of what is displayed on e-paper!(Ascending is without kerning, descending is with kerning.)

[Yardie-]

Strange my replies that I email don't end up here.So I'll add this here. Wow well done I thought that would be a huge job. Fantastic work. The frame buffer idea is wonderful. Something I have just done with my rle code. Which I will probably ditch when you have finished this. It makes the whole process much cleaner and transportable.

How about one of these fonts https://www.1001fonts.com/handwriting+script-fonts.html :)

My Next challenge for you is OTF

If you are interested in e-paper have a look at the new DES ones from good-display the 1.54 2.13 2.66 and 2.9 epapers all have the same driver and code base so now you have the frame buffer stuff working It will be easy to implement for all those sizes.

Most of the code for the larger DES screens seems to be mostly compatible as well.

[Yardie-]

When my DES e-papers arrive and I adapt them to your code and add it to my fork. I also have a lilygo and soon an M5Epaper and will adapt the code for those as well.

[k-omura]

How about one of these fonts https://www.1001fonts.com/handwriting+script-fonts.html :)

After checking some of these fonts, I couldn't find a ttf file with kerning information (kern table). Don't know ttf with kern table? Since kerning is done based on the kern table, it cannot be executed without the kern table ... https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6kern.html

I used to use waveshare electronic paper a lot, but this is also interesting! thanks for the support!

[Yardie-]

Ok well take this font for example https://www.1001fonts.com/alex-brush-font.html if I run convert from imagemagick /usr/bin/convert -kerning 1 -compress none -background white -size 600x -pointsize 72 -font alex-brush.regular.ttf caption:"The Quick Brown Fox" ./test.png

I get this

So the kerning information must be there. I realise that this is a rabbit hole you may not be willing to travel down but I would like to solve this. It seems everyone runs from this problem. Once this is solved the OTF should be easy.

If you email me directly we can chat how to solve this. My email should be visible on my yardie git

[Yardie-]

Wow your latest update was big change. Nice and clean though. I just have to work out the spiffs read part to get it going. Thanks K

:) Greg

[k-omura]

After a little research, I found that in addition to the kerning information based on the left and right character pairs, the layout information for each character is in the 'hmtx' table, so I implemented it. This is an example of displaying an image on EPD using alex-brush.regular.

I would like to consider OTF support based on code size and dissatisfaction with TTF.

[Yardie-]

That is fantastic. Well done. It looks truly amazing and beautiful. The OTF idea was only to extend the capability. But for our purposes this is perfect. Small clean scalable and totally display independent. You should be very proud of your work.

Just saw the example. Sorry

[Yardie-]

Ok just a couple of ideas from someone outside the code. to save confusion maybe call

setStringSize setCharacterSize setStringSpace setCharacterSpacing setStringLine setStringWidth or setStringMaxLength

I also have an old algo for translating utf8 to unicode that I used on your old code. I can drop it in here if you like. utf8 is especially good for European languages and data transfer. Shorter strings and a consistent single byte stream to read. or you could leave it as it is and as I did the user can translate the string to a wchar string encoding the string themselves. I'll hack out a simple example Arduino example once I have time to start working with the code. That is probably the best way I can help you. My cpp is very limited I work and think mostly in C.

[k-omura]

Thanks for the suggestions on the name of the calling function! A nice suggestion for non-native English speaker 👍 Replace sequentially below

setStringSize -> setCharacterSize
setStringSpace -> setCharacterSpacing
setStringLine -> setStringWidth

Also, thank you for your suggestions for single-byte utf8 input. On the backend, I want to use the overload function, just as I would eventually use the wchar (UTF16) input function. I think this is best for simple code.

Currently, there are 3 types of truetype.string, and you can enter wchar_t (UTF16), char (single byte, not working yet), String (UTF8, Arduino string type). There are two options for using UTF8, char type (not implemented) or String type (already available), which method is easier for you to use? (Other methods are also acceptable)

Since it is a String type input, the process of converting UTF8 to UTF16 exists inside the library, but if you like, please drop your code.

Administratively, I'm going to close this kerning issue once and create a new one about UTF8 #5 . Continue over there!

Thank you for your support, Greg!