Oberon space

Цитата: valexey от Апрель 26, 2011, 03:22:44 pm

Для того чтобы возложить что-то на IDE оную IDE нужно иметь :-)

Я все-таки дал курсовику задание сделать IDE для XDS - если дело пойдет то впаяем и 07(но необходимо время для разгона.. 3 курс , хм, толком то и программировать не умеет....).

В рамках этого задания может озадачите студента сделать биндинг к Qt и пусть делает только на связке Qt/Oberon?

Изменять язык для препроцессора я не планирую. Я думаю, это это должна быть внешняя утилита, которая сначала обрабатывает файлы препроцессинга (допустим *.pre) и генерит на основе их ob7 файлы.

Кто что думает по поводу книги "Расширяемые программы" Горбунов-Посадов? Можно ли применить оттуда какие-нибудь идеи?

http://keldysh.ru/gorbunov/index.htm

У меня эта книжка на полке. Два раза читал, до применения руки не дошли, к сожалению.

Для тех, кто не в теме, попробую вкратце пояснить, в чем суть.
Для безболезненного (т.е. без модификации исходного кода) расширения программы используется механизм т.н. "гнезд", т.е. своеобразных разъемов в коде, в который можно вставлять куски кода. Причем речь идет именно о коде во время компиляции, а не о runtime. Использование гнезд позволяет перейти от переписывания кода к дописыванию того, что вставляется в гнезда и последующей сборке. Программирование становится сборочным.

Гнезда, могут использоваться не только по тексту (скажем, в отдельных процедурах или даже в модулях), но и в повторяющихся конструкциях, например, в циклах или в метках case, для чего в гнездах используется соответствующий синтаксис.

Идея в книге высказывается замечательная. Проблема лишь в том, что код при описываемом подходе становится двумерным. Это заметно усложняет транслятор и
дополнительно меняет подход к созданию программы - приходится думать о компоновке и проектировании раньше, чем что-либо начинать писать (что, впрочем, скорее хорошо, чем плохо).

Идея создания гнезд в коде перекликается с точками расширения в ББ и технологией (паттерном?) inversion of control, но эта лишь малая часть из предложенного в книге. Кроме того, это отчасти похоже на обобщенное программирование, хотя подходы Ada к обобщенному программированию в книге разносятся в пух и прах.

Для меня остался нераскрытым вопрос типизации гнезд, т.е. механизм соотнесения между собой гнезда и его содержимого. Кроме того, не совсем не раскрыт вопрос вложения гнезд (в C++, насколько я знаю, вложение templates может привести к огромным накладным расходам при трансляции, поправьте, если не так).

Идея, конечно, просто просится к реализации.

Цитата: Димыч от Март 16, 2011, 06:11:15 pm

Цитировать

расслоение одной линии на три.

Ну где на три, а где и на пять-шесть.
Этот текст отрендерен, вероятнее всего, в рендерере RGBA или BGRA, что дает размытие черного цвета на составляющие при субпиксельном сдвиге. Ничего криминального, нормальный эффект.

Это не так хотя бы потому, что первый образец по определению никто субпиксельно не сдвигал, сдвигали четко на 1 пиксель рывком, так вот, там в точности то же самое расслоение. Кроме того, при определенном значении субпиксельного сдвига расслоение на второй картинке должно было бы полностью пропасть, этого не случилось.

Обе картинки взяты из статьи про рендеринг текста. Та картинка, что со сдвигом в пиксель, сделана с выравниванием по пиксельной сетке; другая с субпиксельным выравниванием/сглаживанием.

Отрисовка шла скорее всего через freetype (agg это умеет), а freetype умеет субпиксельно сглаживать при рендеринге, в отличае от agg. Вообще отрисовка шрифтов не показательна, ибо тут слишком много слоев рендеринга наворочено. В частности зависит и от самого шрифта многое, от того же хинтинга например. :-)

Здесь надо иметь ввиду следующее. AGG достаточно большая библиотека, предназначенная для рендеринга векторной графики. Рендеринг текста в ней делается  сложно - берется шрифтовая информация (набор кривых второго/третьего порядка) для каждого символа и производится отрисовка этой информации (набора кривых). Шрифтовая информация просится у ОС (WinAPI/freetype) или напрямую из шрифтовых файлов (почему нет?).

На графическую поверхность картинку выводит именно AGG, и "гладкая" картинка сделана именно ей. Поэтому AGG и может обеспечить вывод текста с субпиксельной точностью. На практике это означает, что можно позиционировать картинку (текст в том числе) с точностью до 0.1 пикселя (можно и меньше фракцию делать, но видно это начинается где-то с 0.1-0.3 пикселя в зависимости от цвета и примененных фильтров).

PS. Текст в википедии очень уж рекламный и MS-ный.

Хороший DPI это круто, не спорю. На iPhone действительно все смотрится круто.
В Haiku шрифты как рас сглаживаются AGG И там субпиксель это не точка в троеточии, а 1/256 пикселя.
Приведу две картинки с сайта AGG. Один и тот же текст сдвигается на 1/10 пикселя. с субпиксельным сглаживанием и без оного. Там, где логическая точка равна 1/256 пикселя результат оччень даже симпатичный. Но, возвращаясь к вопросу об округлении, чтобы нарисовать линию в один пиксель надо постараться и поиграться с координатами.

Цитата: vlad от Март 14, 2011, 05:03:07 pm

А на мониторах это нифига не работает и реализация не может "правильно учесть растр" - она не может знать в какую сторону ей сместить линию с координатой 0.5 (вверх или вниз), поэтому она рисует две полупрозрачные линии с координатами 0 и 1.

А должна была бы округлить координату 0.5 до целого и нарисовать одну плотную линию в нужном месте с точностью до межпиксельного расстояния. А вот с наклонными линиями тактика всё-же должна быть наверно другой.

Все не так просто. Действительно, получение сглаженных линий толщиной в один пиксель та еще задача!

Для целей сглаживания (anti-aliasing) применяются не пиксельные координаты, а логические. В разных методах сглаживания применяются разные разные способы сопоставления логических и пиксельных координат.  В Qt, например, при выключенном сглаживании пиксели рисуются справа и снизу от логической точки, при включенном сглаживании - вокруг математической точки. В AGG строго вокруг логической точки в любом случае; для рисования примитивов в один пиксель созданы отдельные рендереры.

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

Ну или QuickLisp с ASDF.

https://sourceforge.net/projects/oberonrevival/files/BB/bb-revival-win-0.2.zip/download Может пригодится.
Я первые главы документации переверстал и картинки сделал посимпатичнее. Кроме того, верстку упрощал, чтобы в перспективе в веб переводить.