Как то я позабыл о главном преимуществе векторных картинок над растровыми. С помощью грамотно расставленных delay(); можно реально писать записку, имитируя руку автора.
Это не преимущество, а баловство.
Главное преимущество вектора - это меньший размер файла и правильное масштабирование.
Вы пока освоили рисование букв штрихами единичной толщины. Для более плотных шрифтов надо использовать два вектора - внутренний и внешний, и закрасить пространство между ними.
Ещё плетенкой из пары отрезков - величина расхождения даёт размывание.
Это уже делал на примере конвертирования в расширение plt. Здесь мне не известен алгоритм закраски внутренней области исходя из координат отрезков обрамления.
в этой библиотеке, судя по описаниям, есть функция drawWideLine() - наверное она может вам пригодиться
Что касается закраски, в адафруит она делается штриховкой - то есть рисованием кучи горизонтальных (или вертикальных) линий от одного контура до другого.
Да, функция весьма интересна, судя по переводу комментария к ней в файлеTFT_eSPI.h , соседняя тоже. Надо попробовать применить.
Интересно, а как эти границы определить?
“…я задыхаюсь от нежности. От твоей - моей свежести. Я помню все твои трещинки…”
ты об этом?
Конечно о Земфире, иначе никак.
Ещё одно направление рукописного шрифта это графический ключ. Подделать невозможно (повторить самому тоже не факт) 
При сравнении надо вводить погрешность на совпадения числовых значений координат. Дополнительно конечно темп рисования совпадать должен, иначе число векторов разное будет.
const int buk_A[] = { //
-32,80,-31,81,-29,84,-27,88,-22,89,-14,85,-6,79,2,71,10,60,17,46,22,32,28,22,36,12,43,7,44,6,47,7,47,14,46,22,
42,35,35,49,29,64,25,74,23,82,21,85,21,87,20,91,20,90,666,666,25,57,24,50,17,43,7,37,1,39,-3,41,-8,47,-10,55,-9,66,-6,
75,2,81,10,83,22,85,34,83,45,79,49,75,50,75,51,75,51,75,
};
На правильный ключ ни то ни другое не должно влиять. Сравнивать надо не координаты векторов, а то что получившийся полилайн укладывается в коридор ошибок
Суть не уловил. Раньше подобное, о чём писал выше, делал на примере акустического ключа. Массив хранил длительности между ударами. Потом сравнивались длительности настуканные с ключевыми и с заданной погрешностью сравнивались совпадения.
Это идея, практически не пробовал.
Если ключ - вертикальная линия высотой 100, то ввод пользователя должен укладыватся в прямоугольник высотой 120 и шириной 20. А сколько это будет сегментов - не суть.
Суть уловил, но это усложняет математику - теперь из массива координат концов отрезков надо получить коридор значений и если хоть одна пара вновь получаемых координат не попала в коридор, то ключ не срабатывает… Да, но такой подход пренебрегает ещё и последовательностью рисования символа.
Тут примерно так же, но не во времени, а в пространстве.
Еще одно направление - загнать в вектор элементы лица и забубенить фоторобот-машину на ардуине.
Лица нет смысла, биометрия без покупки лицензии (доогая, для малых организаций не выгодна, да ещё и за каждую транзакцию плата) наказуема штрафом для владельца в 300 круб. А вот по ладони пока можно. Так что я бы в эту сторону посмотрел. Можно не хило иметь с такого контроллера на ардуине. Точно бы в серию пошло.
