Вышла версия 1.3 библиотеки для построения графиков и изображений MathGL.

О! Скриптовый язык это как раз то, что ему не хатало :)

>* появился скриптовый язык - команды рисования можно задавать в текстовом файле и сразу строить графики (с помощью программ mgl2png или mgl2eps),

кто тестил? лучше/хуже чем GNUPlot получилось? понимает ли юникод, раотает ли русский язык?

и на сколько оно быстрее matplotlib?

Выглядит очень интересно. Скажите пожалуйста, возможно ли применять скриптовый язык для картопостроения? Особо интересует возможность подписывания разных изолиний и цветные заливки между ними, в примерах я такого не обнаружил.

и еще - ожидается ли вывод в svg? очень надо ...

Тебе подойдет http://www.pstoedit.net/pstoedit pstoedit -f svg input.eps output.svg

Исходники не распаковываются:

gunzip: mathgl-1.3.tar.gz: unexpected end of file

$ tar xzf mathgl-1.3.tar.gz gzip: stdin: unexpected end of file tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now

Битый архив? Или я что-то делаю не так?

Перезакачай. А потом убей себя об стену.

>Тебе подойдет http://www.pstoedit.net/pstoedit pstoedit -f svg input.eps output.svg

Спасибо!!! Не знал про такое :)

Работает на Ура!!!

> Перезакачай. А потом убей себя об стену.

А не пошёл бы ты нa...x, урод...

>А не пошёл бы ты нa...x, урод...

Поддерживаю.

Точно, какая-то ерунда с закачкой, не смог mgl_script закачать

Привет, Алексей,
на этот раз новость выглядит гораздо более привлекательней.

- хотелось бы иметь "one button installation",
т.е. включить GSL в дистрибутив (естественно, с соответсвенной
configure option), с автоматической компиляцией и запуском demo,
иначе ни один anonymous не осилит.

- думаю, многие на LORe будут страшно рады пакету - это PAW 21го века .. но все это "... мы проходили .."

Главные не достатки PAWшного подхода:

1. статичность - нет обьектов и нет интерактивности манипуляции
с обьектами. Не смотря на то, что используется C++ никакой
обьектной-ориентированности нет. На пример, line - это не обьект,
а метод. "Обьект" нельзя "потрогать".

2. "глобальность" - все атрибуты (цвет, размеры, стиль, и т.д.)
изменяются глобально, a не локально для какого-нибудь конкретного
обьекта.

Правда, что проект оплачивается/лся грантом?

Привет всем!

Сразу извиняюсь за битый архив... Посылал целый :), но что-то с ним в пути случилось ... Только, что заменил на новый.

По поводу вопросов:

1. Русский язык поддерживается. К сожалению, пока есть только один шрифт -- Roman (нет готики и пр., как в английском). Замечу, что ТеХ символы тоже есть.

2. Экспорт в SVG планирую сделать. Скорее всего к версии 1.4 (через месяц или больше). Там будет и прозрачность поверхностей и пр. Пока есть только EPS без прозрачности :(.

3. Закрашивание изолиний пока нет (автоматических подписей тоже). Если надо, то к версии 1.4 сделаю. Сам не пользую, т.к. график плотности по-моему лучше ...

4. Насчет статичности, тут не совсем так. В растровом формате действительно выделить один объект сложно. Поэтому возможность редактирования объектов принесена в жертву качеству и скорости рисования. В векторном формате (сейчас EPS), де-факто, объекты хранятся по отдельности и если надо, то их можно редактировать. Однако на мой взгляд проще переписать скрипт или программу (если строится несколько однотипных рисунков), чем на каждом рисунке редактировать объекты.

5. Глобальности тут совсем нет. Каждое изменение стиля, цвета и пр. коснется только объектов нарисованных после изменения (есть некоторые исключения в OpenGL режиме). Другое дело если вы не указываете стиль объекта, то будет использована предыдущие параметры. Причем если вы используете несколько экземпляров классов рисования (или разбора скрипта), то в каждом из них настройки независимые.

6. Проект грантом не оплачивался. Это моя личная инициатива. Можно и на даты создания файлов посмотреть :).

> * появился скриптовый язык

А почему свой скриптовый язык, а не, например, Python? Просто любопытно, в чем выигрыш.

Причин две:

(1) командный язык легче (быстрее) исполнять и программировать, чем полноценный алгоритмический язык;

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

Если кто-нибудь напишет Python-интерфейс, то это всячески приветствуется :).

> 1. Русский язык поддерживается. К сожалению, пока есть только один шрифт -- Roman (нет готики и пр., как в английском). Замечу, что ТеХ символы тоже есть.

Возможно не в тему, а почему не опереться на шрифты cm-unicode? http://canopus.iacp.dvo.ru/~panov/cm-unicode/ - здесь есть все начертания и кириллица из коробки, а так же полное согласие с математическими TeX-шрифтами.

Честно, говоря нашел только один тип свободных векторных шрифтов. Попробовать с cm-unicode можно, но пока немного руки не доходят -- вроде и так все работает, а смена шрифта -- это скорее украшательство.

Первый аналог (не полный, естественно) что приходит в голову, когда читаешь описание это gnuplot.

gnuplot хорош в частности тем, что там довольно чёткий набор команд, может быть имеет смысл оттуда их "утащить"?

> Честно, говоря нашел только один тип свободных векторных шрифтов. Попробовать с cm-unicode можно, но пока немного руки не доходят -- вроде и так все работает, а смена шрифта -- это скорее украшательство.

IMHO, шрифты это не украшательство. На сегодня - это один из основных тормозов тотальной кириллизации, если не основной. Нормальная работа со шрифтами - это _очень_ большой плюс. Кстати, gnuplot это умеет.

Свободных с кириллицей дествительно мало. А свободных, с кириллицей, которые и при печати прилично выглядят с полным набором начертаний, так это только Computer Modern и остаётся. Панов свой дистрибутив допилил, чтобы Computer Modern и при низких разрешениях выглядел получше.

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

Я пошел по-второму пути. Фактически скриптовый язык почти дословно повторяет функции библиотеки, а сам скрипт - почти С++ программа (но без скобок около функций :) ). В этом плане язык вполне четкий. Некоторая нечеткость возможно связана с формулировками (все таки первая версия).

Единственное чего возможно не хватает - выделения подмассивов прямо аргументе команды. Пока это приходится делать в два шага. Возможно в будущем добавлю такую возможность.

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

Про совместимость я даже и не заикаюсь. Это не реально. Я просто к тому, что мне нравится синтаксис команды plot для 2D в gnuplot, возможно, по привычке.

используются hershey stroke fonts, что выглядит "коряво".
в ROOTe используется FTGL lib
http://homepages.paradise.net.nz/henryj/code/#FTGL
для отрисовки true type fonts в GLe

рекомендую посмотреть

> используются hershey stroke fonts, что выглядит "коряво".

Имеются в виду шрифты с засечками? Где используются? И почему коряво?

> для отрисовки true type fonts в GLe

Для кириллицы пока нет полного набора TrueType шрифтов с нормальным выводом на печать (я не знаю можно ли на автомате конвертироват Type1 без потерь). Так что случае ROOT и кириллицы - единственный выход, это LaTeX+пакет psfrag.

>> для отрисовки true type fonts в GLe

Сходил таки по ссылке. Я это раньше даже смотрел - это к сожалению, как обычно, не то, что нужно.

> http://canopus.iacp.dvo.ru/~panov/cm-unicode/

спасибо за ссылку, но не понятно, почему нельзя
просто взять M$ TTF фонты?

> спасибо за ссылку, но не понятно, почему нельзя просто взять M$ TTF фонты?

Они не очень качественны при печати и это нельзя исправить никак. Ну и не сочитаются с математикой.

> 3. Закрашивание изолиний пока нет (автоматических подписей тоже). Если надо, то к версии 1.4 сделаю. Сам не пользую, т.к. график плотности по-моему лучше ...

Я не про то ... Если взглянуть на карту, на которой например нанесены линии, имеющие одну и ту же высоту над уровнем моря, то можно увидеть, что в некоторых местах линии прерывается и в месте разрыва стоят циферки, показывающие эту самую высоту, причем если их несколько, то всё число иногда "кривое", повторяющее линию. Ну а кроме высот могут быть например давления, глубина, и еще туча других характеристик. Это пожалуй единственное, что при использовании gnuplot у меня не получилось.

> Я не про то ... Если взглянуть на карту, на которой например нанесены линии, имеющие одну и ту же высоту над уровнем моря, то можно увидеть, что в некоторых местах линии прерывается и в месте разрыва стоят циферки, показывающие эту самую высоту, причем если их несколько, то всё число иногда "кривое", повторяющее линию.

Я не совсем понял какой момент является принципиальным:

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

2. Линии уровня с цифрами именно в разрывах. При этом можно наложить линии уровня (например, однотонные) на сглаженную картинку (график плотности или поверхность).

3. Линии уровня, наложенные на картинку с резкими границами цвета.

мммда ... недолго новость пробыла на первой странице ...