Встроенный в библиотеку шрифт пригодится если делать сервер с расшаренной памятью.

Sorcerer wrote:Это 16пкс. Спасибо Мне бы алгоритм автохинтинга... Попробую у экспертов спросить.

А может быть автохинтинг и правда ненужен? Я прочитал статью, которую ты привел в пример: http://habrahabr.ru/blogs/typography/112401/
Надо сказать что автор в многом прав.
Там обходятся без хинтинга, а результаты впечатляют. А альгоритмы которые они используют позволяют позиционироваться по X на 1/256 пикселя. Альгоритмы ети смотрятся не очень сложными. Может стоит попробовать их.

Я отчасти основывался и на мыслях автора в том числе. Теоретически мой алгоритм позволяет позиционировать букву по оси X на 1/768, и по оси Y на 1/256 пиксела.

upd: Оказывается, мои сегодняшние усовершенствования алгоритма - это и есть "автохинтинг". Ха-ха.

upd2: цитирую:

Короче говоря, для приятного глазу текста и при этом сохранения аккуратного горизонтального позиционирования нам нужно следующее:
1. Использовать горизонтальный субпиксельный RGB-анти-алиасинг на мониторах LCD.
2. Использовать только вертикальный хинтинг и полностью отказаться от горизонтального.
3. Использовать точные значения смещения глифов, вычисленные на высоком разрешении для глифов без хинтинга.
4. Использовать точные значения высокого разрешения из таблицы кернинга.

1 - выполнено.
2 - так и есть, только хинтинг автоматический и неагрессивный
3 - именно так все и будет в ближайшем будущем
4 - надеюсь, что так и будет

Оптимизирую алгоритмы растеризации, есть мысли, как ускорить процесс в сотню раз для крупных символов и в несколько раз для небольших.

Тем временем, очень интересно было бы узнать что-нибудь о градиентных и текстурных заливках. Они будут нужны для SVG. Я начинаю представлять, как сделать градиенты и blur, но всё еще не знаю, как с их помощью можно залить объекты.

Sorcerer wrote:Я начинаю представлять, как сделать градиенты и blur, но всё еще не знаю, как с их помощью можно залить объекты.

Думаю что для этого тебе понадобится создавать буфер с градиентом и с контуром фигуры. При рисовании в основной буфер должно происходить наложение этих буферов как через трафарет. В одном из примеров использования библиотеки buf2d я выкладывал пример с трафаретами.

Понятно.Думаю,я обращу внимание на buf2d.Спасибо!

От шрифтовых работ начала закипать голова (к тому же я написал письма нескольким разработчикам всяких FreeType с вопросами, но ответов пока не получил, а может письма просто не дошли), и я решил немножко заняться SVG, который мне так мил
И вот первые результаты работы по разбору контуров: Слева - растеризовано-не-знаю-чем-в-inkscape-но-наверное-libsvg, справа - моей простой программкой. Относительные координаты распознаются несколько криво, из-за этого одна из частей контура оказалась в (0,0), а не там, где должна была быть. Как видно, никаких проблем с самопересечениями не имеется. Не скажу, что работает быстро, скорее наоборот. Пока что не работает вывод более чем одного контура, отсутствуют градиентные заливки, обводка контуров, полупрозрачность, блюр, анимация (:mrgreen:) и многое другое. Есть еще куда расти

Начинал писать свои программы я на ассемблере, но посмотрел строгим взглядом на код, и понял, что переписывать их нужно с нуля. К тому же для незначительных правок алгоритма нужно было править кучу кода, поэтому тот растеризатор, что я показывал последним, написан на Си. Аналогично, текущая версия программы "просмотра" контуров из SVG так же написана на Си, и мало чем отличается от растеризатора шрифтов (а парсера SVG никакого пока что нет, я разбиваю тег d из SVG файлов полуавтоматически с помощью букмарклета). В ассемблере я пока что почти полный ноль, и мне нужна очень значительная помощь в реализации библиотеки шрифтов. Всех заинтересованных, желающих и способных помочь прошу написать мне ЛС. Нужно как минимум обсудить API библиотеки. Так же мне нужна помощь при работе с FPU (а может, способы обойтись без FPU), и многое другое.

Технические детали:

Spoiler:

Общая часть растеризатора - 8 строк на Си, простой растеризатор - еще 3 строки, АА растеризатор - еще 9 строк, cleartype-like растеризатор - около 20 строк кода. Это все, что есть важное в растеризаторе (эх, а сколько раз оно переписывалось ). Вспомогательный код по разбору контуров из SVG у меня в отдельной программе, и, в принципе, его вообще можно не включать в библиотеку (а можно и включить, чтобы поддерживать настоящие SVG-шрифты). Еще нужен код для записи растеризованных глифов в память и составления из этих глифов строк с учетом расстояний между глифами, и этим я практически не занимался, есть только общие мысли по этому поводу.

Работы прилично много, но она реально выполнима. Я мог бы справиться с ней в одиночку, если бы продолжил разработку на Си. Но не комильфо. Поэтому я надеюсь на вашу помощь

SVG же подмножество XML - нельзя попробовать библиотеку XML на fasm?

Она занимает в скомпилированном виде сколько? 20 килобайт? С одной стороны немного, а с другой растеризатор занимает сейчас килобайта два-три. Если бы библиотека была обычной Колибри-библиотекой, было бы здорово - импортировал нужные функции, и работай себе с XML на здоровье. А линковать статически - смысла не вижу. Если кто-нибудь мог бы заняться библиотекой XML (или меня уверили бы в острой необходимости такую для Колибри заиметь в ближайшее время) - то смысл бы сразу появился.

Я посмотрела на библиотеку asm-xml, и она практически идеальна для портирования как динамической библиотеки. Портированный вариант с примером использования я сейчас выложу в соответствующей теме.

Оптимизировал и серьезно поправил алгоритм.
На глифах размером 16x16 работает вдвое быстрее, а на глифах 24x24 точки - примерно в 10 раз быстрее. Для глифов около 600x600 точек новый алгоритм работает примерно в 30-40 раз быстрее.
На моем тестовом 2 ГГц Celeron глиф 16x16 рендерится примерно за 1 мс в режиме отладки (а он, как показывает практика, примерно в 3 раза медленнее обычной работы программы). Глифы размером 4000x4000 точек выводятся чуть более чем за секунду, а это, я считаю, не такой уж и плохой результат.

upd: на той же машине в подобных условиях запустил бенчмарк FreeType 2.4.4. Без сглаживания 10x10 пикселей - 10мс/глиф, 24x24 пиксела - 15 мс/глиф, 600x600 - 275мс/глиф. У моего алгоритма (пока что отлаживаю его на ЯВУ, реальная скорость должна быть выше) 10x10 пикселей - около 5 мс/глиф с выводом на экран и менее 1 мс/глиф в ОЗУ. 600x600 - около 250мс/глиф. Кстати, похоже FreeType жульничает: глиф 4000x4000 по заверениям ftbench рендерится за 250мс, то есть быстрее, чем 600x600. С другой стороны, в TTF-шрифтах глифы 2000x2000 точек, так что все может быть...