ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
29 марта
863375 Топик полностью
fk0, легенда (17.08.2018 01:48 - 01:57, просмотров: 150) ответил LightElf на Я наверно не понял твоей мысли. Исходный шрифт у меня в TTF, это объективная реальность. Конечный шрифт (в памяти мк) будет в каком-то своем бинарном формате (раз уж TTF требует слишком много оперативки). Зачем нужен BDF? Почему не конвертировать
Затем, что ты не знаешь и не имеешь идей как содержать в памяти шрифт, и затем, что у тебя нет на самом деле "толпы конвертилок" и нет самих шрифтов. Есть простой bdf, есть нифига не документированный линуксовый pcf, что ещё можешь назвать? Вся https://en.wikipedia.org/wiki/Portable_Compiled_Format
"толпа конвертилок", редакторов шрифтов и сопутствующих программ работает с ограниченным множеством стандартных форматов пришедших из windows или X11/linux (может быть с Amiga ещё, с Windows 3.11 -- только сейчас и софта уже не найти). Все прочие шрифты уже не растровые. И конвертировать любой векторый (TTF без битмапов, Type1 из postscript и т.п.) шрифт в растровый хрен так просто выйдет. Если шрифт с хинтингом и у тебя есть сглаживание -- ну может быть и кое как. Руками рисованные растровые шрифты ПРИНЦИПИАЛЬНО ОТЛИЧАЮТСЯ. И сами растровые шрифты, ты их можешь найти только там где они ещё могут хотя бы теоретически использоваться. В том же линуксе где есть X11 обычно есть много пакетов с хорошими растровыми шрифтами. Они скорей будут в BDF или PCF, или их можно загрузить в редактор (например xmbdfed) и сконвертировать. Да тот же xmbdfed шрифты тебе даст без самих файлов шрифтов, просто из оконной системы. Вопрос куда сконвертировать. В формат имени сеггера тебе сконвертировать нечем, да и сам формат сомнительный. Вот я тебе и предлагаю текстовый BDF разобрать в бинарный вид и так хранить в МК (в бинарном виде). В википедии есть ссылка на адобовскую документацию со всеми подробностями. В зависимости от того, как у тебя сделана отрисовка, тебе половина полей из BDF возможно не нужна, так что задача сильно упрощается. Скорей тебе нужен только таблица символов (на входе код в ISO8859-5, на выходе смещение от начала файла или ноль, ну или может юникод на входе, см. ниже), и для каждого символа bounding box, dwith и битмап собственно. Вектора, метрики и прочее не нужно, можно при парсинге откинуть. Текст у тебя может быть только слева-направо (mode 0), глифы накладываться могут (для наклонных шрифтов например), пар (типа ff, fl, fi...) не будет. Если входной алфавит очень широкий (UCS2, UCS4, или UTF-8 трансформируемый в какой-то UCS), то можно сделать хеш-таблицу, по аналогии как описано здесь: https://docs.oracl …90/chapter6-48031.html Входом является код символа, выходом ссылка на его описание (или его отсутствие). Сами битмапы лучше не по-адобовскому хранить, а развернуть на 90 градусов. Вообще это от дисплея зависит. Просто идея в том, что все символы сильно разной ширины, а высота примерно всегда одинаковая. И чтоб не терять биты хранить не битмап из горизонтальных строк, а из вертикальных столбцов, где число столбцов (байт) зависит от ширины символа. Но если у тебя уже есть графическая система (та же X11), то возиться с битами смысла нет, проще в её формате хранить (X11 и Win32 GDI умеют свои битмапы уже, и умеют их быстро скопировать в окно). Т.е. ещё раз, описание символа это просто сишная структура, где поля bbox, dwith и смещение на битмап относительно начала файла шрифта (структуры из хеш таблицы или просто таблицы (пере)кодировки могут адресоваться по-индексу, поэтому должны иметь одинаковый размер, а битмапы все разные). Как-то так. Боюсь зря бисер метал. Да, может я не прав и PCF не так уж и страшен как малюют: https://fontforge. …/reference/pcf-format/ В том смысле что это как бы бинарный аналог BDF. Но там сразу вылезают проблемы с эндианностью, с направлением битов в битмапе (слева-направо или справа-налево), с выравниваниями. Распарсить же BDF и положить в удобные для себя структурки с нужными ендианностями и т.п. -- по-моему лучше.
[ZX]