Поиск шрифтов для термо-принтера
Однозначно надо сначала как-то упростить задачу использования шрифтов, поэтому будем искать только моноширинные, т.е. у всех символов одинаковая ширина.
моноширинные шрифты
Интернет подсказывает это :
Consolas (англ. Consolas)
Courier и Courier New
Lucida Console (англ. Lucida Console)
Terminus
Monaco (англ. Monaco)
Anonymous Pro
Есть такая программа Microelectronica GLCD Font Creator 1.2.000 (по-видимому бесплатная). Там можно загружать из системы (под Windows) ее шрифты и под разные размеры квадрата пикселей. Т.е. происходит адаптация символов под разные размеры системных шрифтов :
console обычный (пробуем для латиницы 32 .. 127)
16 : Consolas12x21 (X-GLCD : 1 символ 37 байт)
8 : Consolas6x11 (X-GLCD : 1 символ 13 байт)
7 : Consolas5x9 (можно убрать сверху ряд - microC GLCD Lib : 1 символ 5 байт)
6 : Consolas4x9 (можно убрать сверху ряд - microC GLCD Lib : 1 символ 5 байт)
При экспорте выбираем обязательно microC GLCD Lib. Это формат представляет символ 5*8 как 5 байт.
Но есть нюанс , если НЕ убрать вручную ряд или столбец , то вариант microC GLCD Lib может быть не доступен. Глюк это или защита каких-то прав ...
На самом деле ответ очевиден , смотрите сообщение при экспорте появляется "Font height > 8bits Only X-GLCD lib available".
Логично мы столбец должны вписать в 1 байт (8 точек) и если высота больше 8 символа, то это не получится.
Почему именно надо 8 точек по высоте на символ?
LCD экраны обычно изготовлены для вывода символов именно 8 точек по высоте.
Для термо принтеров это наоборот не проблема , т.к. обычно самый дешевый принтер имеет 384 по ширине и можно шириной 5 1(пробел) выводить 64 символа в строке , но это реально очень мелко. И приходится удваивать, утраивать точку прорисовки банальным повтором точки по горизотнтали и по высоте. При этом качество самого такого символа как-бы желает быть лучше.
Если использовать 16*16 символ X-GLCD , то в строке печатается 24 символа - ТО , ЧТО НАДО для визуального восприятия. Но на один символ уйдет примерно 37 байт, вместо 5 байт при 5*8 microC GLCD Lib.
А если мы хотим в микроконтроллер приличную часть юникода загрузить, с поддержкой Европы и не только ?
Теперь у console находим только 5*9 с возможностью обрезать сверху/ снизу , но это не есть Гут.
Ищем короче размер 5*8 среди других моноширинных шрифтов:
Находим Courier New 7 обычный (32 .. 127) -> 5*8 сразу четкое попадание.
Теперь мы хотим допустим добавить кириллицу в свой набор.
А вот для кириллицы 0x04xx юникод для Courier New 7 обычный получаем уже 5*11 , т.к. большие Ё, Й сверху имеют точечки,завитушки. И их отрезать нельзя никак.
Ищем еще варианты латиница и кириллица 5*8:
Lucida Console
загружаем символы с 0x0400 (1024) по 0x4FF(1279) :
LAT Lucida Console 7 обычный :
Cyr Lucida Console 7 обычный : 5*9 (уже ближе к 5*8)
А если мы захотим добавить поддержку Армянского, Грузинского юникода , а там завитушки посложнее будут. Что делать?
Надежнее использовать Не 5*8 , а что-то по масштабнее.
вариант 8*13
Это например LAT Lucida Console 10 обычный ! (8*13 : 13 байт на символ)
Приходит в голову вариант сделать побольше 8*13 .
Чем он хорош : данные храним также побайтово, только теперь 1 байт = 1 ряд, и таких рядов 13шт.
Примечателен этот вариант тем , что визуально очень легко читается и создать алгоритм вывода точек на принтер еще и проще будет.
И вот момент истины :
Кириллица Lucida Console 10 обычный дает тоже 8*13 . То есть размер символа латиницы и кириллицы один и их можно объединять в один набор юникода без проблем.
Для возможности дальнейшего расширения набора юникода попробуем проверить Армянский
Опять Lucida Console 10 (обычный) загружаем с 0x0530 (1328) по 0x058F ()1423 и получаем матрицу символа 8*11 !. То есть даже меньше размер получается.
Но это не беда , т.к. можно убрать галочки :
Common blank Rows at TOP of all chars и Common blank Rows at BOTTOM of all chars
И тогда на выходе получаем Lucida Console 10 (обычный) : 8*13 . Теперь можно смело армянский добавить в свой набор. А почему бы и нет?
Понятно , что иероглифы скорее всего не влезут в 8*13 , но уже полмира мы можем поддерживать.