Board.KolibriOS.org

Да, согласен. В разных шрифтах - разные "родственники". Я сейчас вожусь с Курьером 9х16, там двойников больше и буквы тонкие - как раз то что надо. Размер 31х63 конечно абсурдно большой, я просто забил 6 бит на Y и 5 бит на Х, чтоб на все случаи жизни хватило. Мало ли что, может кто захочет себе крупный фонт 36х20 забабахать? Хотя на больших глифах конечно у безье-шрифтов будет преимущество в размере (но не в скорости отрисовки).
Будет шрифт - будет и тест (MGB устроит в качестве непредвзятого теста?) .
Работка действительно муторная (я пока только до цифры 3 дошел), но чем дальше в лес- тем чаще партизаны - тем больше общих линий.

Наверное;) катит только твой вариант только для тонких шрифтов, а это не годится для шрифтов в браузерах, продвинутых редакторах. А вместо старых системных-идея хорошая. Вместо запатентованного шрифта может лучше использовать что-то свободное и похожее?

Сейчас хотя бы что-нибудь читаемое, а то глаза совсем сели.
А потом - посмотрим на результаты.

Идея не новая - в Apple II так кодировались спрайты чтобы быстро рисовать из Бейсика. Только назывались не спрайты, а как то по-другому (память уже не та...)
Разумно сделать кодировка 4-х битная. 3 бита на направление и 1 на действие - перемещение/рисование.
Кстати, эти изображения по существу векторные и их можно мащабировать.

johnfound
Масштабировать (х2, х3) конечно можно, но получится коряво - также как Zoom для маленьких растровых шрифтов.

Конечно идея стара как мир. Я помню более древние времена: в Turbo Pascal 3.0 была библиотека черепашьей графики, где трак тоже запоминался 4-битовыми цепочками.
И даже еще более древние: именно такой принцип кодировки был зашит в ROM (матрица с тысячами вручную впаяных диодов!) чуда советской электроники - векторно-растрового дисплея РИН-609.

Только всё-таки 3 битная кодировка линий на 25% короче. И даже такая упаковка оказывается избыточной: для плавных линий (без острых углов) можно обойтись и двумя битами на пиксель.

Кодировка не все. Альгоритм рисования все. Ничего не мешает масштабировать х1.5 или х21.333 например.
Но в конце концов, лучше иметь полностью масштабируемые шрифты. Работа Sourcerer-а выглядела вполне перспективная. Жаль, человек на ассемблере не пишет и дело затягивается.

Думаю,что на небольших размерах можно шрифты с помощью моего алгоритма делать,хотя и выйдет не так компактно,как вручную

Ну не годятся все эти безье и сплайны для маленьких букв. Для больших - да, нужно.
А 10-пиксельная линия всегда будет выглядеть коряво, даже с антиалайасингом.
Поэтому в комплекте к любому приличному шрифту всегда поставляются несколько его экранных версий в разных типоразмерах.
Допиленных вручную.

http://en.wikipedia.org/wiki/PostScript

Что верно - то верно. Ручно нарисованные шрифты всегда лучше.

turtle-графика открывает возможности для сколь-угодно глубокой детализации не только шрифтов... но и элементов интерфейса

XVilka
Одних turtle-линий для GUI недостаточно.

Нужно уметь определять (и переопределять на лету) кнопки, линии, фигуры, заливку, битмапы, градиенты -- всё, что сейчас крутится через GUI-функции.

Т.е. нужен полноценный метаязык, и [ядерный] парсер к нему.

Выделена тема Опять про X и Linux, просьба не загаживать больше эту тему оффтопом.

по поводу метаязыка - что, если взять XML-метаязык, разработать/допилить спеки, а потом перевести в binary-xml? Быстро, компактано, и сравнительно легко парсить

Вот библиотека, для парсинга binary-XML https://libwbxml.opensync.org/