Sorcerer wrote:Увы, это только для части пиксельных шрифтов так.В реальности каждая буква иногда очень сильно отличается от своих родственников. ... кстати,к вопросу о букве б.Предлагаю тем же tahoma размера 16-20 (это гораздо меньше 63 пкс в высоту) набрать рядом буквы б и о. Разницу видно невооруженным глазом.
Да, согласен. В разных шрифтах - разные "родственники". Я сейчас вожусь с Курьером 9х16, там двойников больше и буквы тонкие - как раз то что надо. Размер 31х63 конечно абсурдно большой, я просто забил 6 бит на Y и 5 бит на Х, чтоб на все случаи жизни хватило. Мало ли что, может кто захочет себе крупный фонт 36х20 забабахать? Хотя на больших глифах конечно у безье-шрифтов будет преимущество в размере (но не в скорости отрисовки).
Sorcerer wrote:Насчет скорости-хочу непредвзятый тест производительности.И еще проблема-кто шрифты рисовать-то будет?Тяжелое и неблагодарное занятие.
Будет шрифт - будет и тест (MGB устроит в качестве непредвзятого теста?) .
Работка действительно муторная (я пока только до цифры 3 дошел), но чем дальше в лес- тем чаще партизаны - тем больше общих линий.
Наверное;) катит только твой вариант только для тонких шрифтов, а это не годится для шрифтов в браузерах, продвинутых редакторах. А вместо старых системных-идея хорошая. Вместо запатентованного шрифта может лучше использовать что-то свободное и похожее?
art_zh wrote:Есть задумка сделать системные шрифты векторными, но НЕмасштабируемыми.
Идея не новая - в Apple II так кодировались спрайты чтобы быстро рисовать из Бейсика. Только назывались не спрайты, а как то по-другому (память уже не та...)
Разумно сделать кодировка 4-х битная. 3 бита на направление и 1 на действие - перемещение/рисование.
Кстати, эти изображения по существу векторные и их можно мащабировать.
johnfound
Масштабировать (х2, х3) конечно можно, но получится коряво - также как Zoom для маленьких растровых шрифтов.
Конечно идея стара как мир. Я помню более древние времена: в Turbo Pascal 3.0 была библиотека черепашьей графики, где трак тоже запоминался 4-битовыми цепочками.
И даже еще более древние: именно такой принцип кодировки был зашит в ROM (матрица с тысячами вручную впаяных диодов!) чуда советской электроники - векторно-растрового дисплея РИН-609.
Только всё-таки 3 битная кодировка линий на 25% короче. И даже такая упаковка оказывается избыточной: для плавных линий (без острых углов) можно обойтись и двумя битами на пиксель.
art_zh wrote:johnfoundМасштабировать (х2, х3) конечно можно, но получится коряво - также как Zoom для маленьких растровых шрифтов.
Кодировка не все. Альгоритм рисования все. Ничего не мешает масштабировать х1.5 или х21.333 например.
Но в конце концов, лучше иметь полностью масштабируемые шрифты. Работа Sourcerer-а выглядела вполне перспективная. Жаль, человек на ассемблере не пишет и дело затягивается.
Ну не годятся все эти безье и сплайны для маленьких букв. Для больших - да, нужно.
А 10-пиксельная линия всегда будет выглядеть коряво, даже с антиалайасингом.
Поэтому в комплекте к любому приличному шрифту всегда поставляются несколько его экранных версий в разных типоразмерах.
Допиленных вручную.
Wiki wrote:One issue is that fonts do not actually scale linearly at small sizes; features of the glyphs will become proportionally too large or small and they start to look wrong. PostScript avoided this problem with the inclusion of hints which could be saved along with the font outlines. Basically they are additional information in horizontal or vertical bands that help identify the features in each letter that are important for the rasterizer to maintain. The result was significantly better-looking fonts even at low resolution; it had formerly been believed that hand-tuned bitmap fonts were required for this task
по поводу метаязыка - что, если взять XML-метаязык, разработать/допилить спеки, а потом перевести в binary-xml? Быстро, компактано, и сравнительно легко парсить