[sK1 project] Разработка векторного редактора.

Лучше займитесь поддержкой svg2.0 и предложите это разработчикам огнелиса и inkscape'а.

> принято решение начать всё с нуля.

ну вот приехали...

какой функционал для этого нужен?

cdr

А спецификация svg2.0 уже опубликована? Я слышал только про черновики.

Четыре буквы: CMYK

Решение было принято с болью в сердце но эволюция зашла тупик.

Код доставшийся в наследство от скенцила устарел.

Относительно взаимоотношений sK1 и UC: последний должен стать независимой подсистемой в sK1. Модель, функции для работы с моделью, шрифтовая система, управление цветом, работа с растром, рендеринг, фильтры импорта/экспорта будут в UC. А в sK1 останутся UI и логика приложения. Причем они должны быть независимыми, чтобы можно было легко менять виджетсет.

Дело в том, что gtk хорош для Ubuntu, но для портирования на венду и мак лучше Qt.Кдешникам тоже Qt больше по вкусу, чем gtk. Нерешенный пока вопрос - рендерер. В Qt логично использовать QPainter, а не Cairo. Тем паче, что на маке у cairo свои косяки. Поэтому сначала сделаем gtk версию (порт на венду возможен), а потом будем экспериментировать с qt.

Ещё четыре буквы: GIMP, и мы засаммоним ирсю.

> В команде разработчиков было принято решение начать всё с нуля.

Требуется обозначить цели и что в конечном итоге мы хотели бы получить

Как-то странно у вас вопрос стоит. Обычно решение писать с нуля принимается потому, что достичь нужных параметров на данной кодовой базе сложнее, чем написать с нуля. Т.е. чтобы достичь уже заданной цели, надо всё переписать. А не как у вас - сначала переписать, а потом понять зачем.

На работу с tk виджетсетом уходит более 50%, остальное время тратится на поддержание кода в актуальном состоянии.

Код компонентов перемешан, что постоянно приводило к появлению регрессий.

В итоге пришли к выводу, что переписать будет быстрее.

>Ещё четыре буквы: GIMP, и мы засаммоним ирсю.

Парсер сломался читать.

Не знаю кто такой ирсю но с редакторами растровой графики и CMYK действительно беда.

Потребуется ли в sK1 инструментария для примитивной правки растра или нет и на сколько это будет востребовано я пока не знаю.

А чем вас черновики не устраивают? Очень хочется нормальное 3D в браузерах...

Равняйтесь на возможности CorelDraw - не ошибетесь :))

3D и анимация в наши планы не входила.

CorelDraw отнють не идеал. Для примера в кореле поддерживается туева куча цветовых моделей которые на практике не используются совсем.

>редакторами растровой графики и CMYK действительно беда.

Можно сделать как в Скрибусе - правкой во внешнем редакторе. Не сильно гибко, но пользоваться можно.

Ещё предложение, в том же Скрибусе сначала рисуется рамка рисунка. В неё загружается изображение, которое можно масштабировать и двигать x,y. Удобно, например в случае, когда надо разместить 20 человеческих лиц одинакового размера на странице. Подвинул физиономию по-центру, увеличил/уменьшил - красота.

С другой стороны, это не всегда удобно, когда надо быстро вставить изображение. Оба варианта (обычная вставка и вставка в рамку) было бы идеальным решением.

Не на плюсах.

Архитектура приложения: http://ru.wikipedia.org/wiki/Model-View-Presenter

Модель будет на чистом python

Методы для работы с моделью будут в одном экземпляре в Presenter объекте и видимо будут основаны на lib2geom (ее функционально ориентированная архитектура самое оно для MVP)

С виджетами, как я уже писал выше, пока остановились на GTK.

А вообще что может потребоваться сделать с битмапом уже внедрённым в документ кроме как поменять разрешение, подправить тоновыми кривыми и сменить цветовую модель?

>А вообще что может потребоваться сделать с битмапом уже внедрённым в документ кроме как поменять разрешение, подправить тоновыми кривыми и сменить цветовую модель?

Клонированный штамп, кисть. Минимальная цветокоррекция (яркость/контрастность, тон/насыщенность/осветление, кривые). Sharpen для увеличенных изображений. Маска (увод части изображения в альфу). Губозакатачная машинка (для меня).

Это всё необязательно для жизни. Написал в порядке уменьшения нужности (имхо).

Продублировал вашу мысль в форуме на linuxgraphics

можете сделать нормальный импорт из png?

ну что ж будем ждать. наlеюсь будет по-производительнее inka

надеюсь

Было бы круто иметь поддержку экспорта в FLA и SWC.

что это за форматы FLA и SWC. поподробней пожалуйста.

> можете сделать нормальный импорт из png? вы имеете в виде экспорт в png? просто проблем с импортом png я не замечал.

В команде разработчиков было принято решение начать всё с нуля.

Пишите на Java с использованием SWT.

Возможно он имел в виду трассировку.

>В Qt логично использовать QPainter, а не Cairo.

Аккуратнее с Qt. Вон, kword отображает шрифты очень криво, потому что кутишная штука для работы со шрифтами имеет проблемы в хинтинге и ещё чём-то. Багрепорт у кутей висит, но при этом они не обещают, что поправят в ближайшее время, т.к. «Qt не пытается быть библиотекой для всего, у нас немного другие задачи. Исправим может быть в будущем, это не приоритетно.»

Так что cairo будет неплохим вариантом в любом случае.

Несложный тест новой модели из 10000 кружочков, конвертированных в кривые Безье (5 точек) показывает, что Инкскейп использует ~1.5Gb, Corel и sK1 0.9 ~ 200Mb. А новая модель использует всего 10 Mb. Преимущества как бы очевидны.

Но пока сложно что-то прогнозировать.

>Возможно он имел в виду трассировку.

Для трассировки мы планируем использовать potrace.

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

> Поэтому сначала сделаем gtk версию (порт на венду возможен), а потом будем экспериментировать с qt.

Лучше уж сразу на Qt, портировать с GTK на Qt невозможно, только полное переписывание.

По поводу рендерера. Не так давно Nokia выступала с заявлением что планирует в Qt отрисовку ускорить в несколько раз. Подробностей не помню.

GTK'шный GIMP под Linux ещё более-менее, но под вендой - лучше перед сном не видеть.

> Модель будет на чистом python

Сколько ни пробовал юзать софт на Python, всё кончается плачевно - либо софтины начинают есть проц на 100% (поищите в том же багтреке Deluge - наверно самая регулярно возникающая проблема во всех частях программы), либо едят память.

> которые на практике не используются совсем

Субъективно же.
Вы может и не используете, а кто-то - использует.

За один присест скопировать функционал корела или илюстратора не получится, надо сначала выбрать что повкуснее.

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

Тогда другой пример. Поддержка формата dxf. На кой чёрт она сдалась полиграфистам? Всё можно разрулить через реализацию импорта/экспорта pdf.

Могу ошибаться.

> В команде разработчиков было принято решение начать всё с нуля.

Ну очень характерная черта разработчиков из бывшего СССР.

Про запросы.

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

Так хоть есть какой-то шанс, что проект не загнется на ранней стадии.

Не на плюсах.

Какая тебе разница как пользователю?

Не как пользователю. А чтобы не загнулось.

>>Четыре буквы: CMYK

Три буквы: ***!

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

Просто однажды кто-то должен сесть и написать универсальный движок такой конвертации. А вмазывать разноперые костыли в каждый пейнт - это прыщавые полумеры.

подобрал бы кто кодовую базу XaraLX. шустрый движок, заточенный под задачу, сами создатели писали, что в разы быстрее cairo; правильная лицензия; любители корела всегда писались кипятком — привычный для них воркфлоу.

sK1 до прыщей еще не дорос. Проекту только восемь лет без малого :)

Да движок у XaraLX быстрый, но по моему не открыты, только бесплатный.

Я, возможно глупость спрошу, но все таки. Отсутствие такого свойства обводки, как «внешняя/внутренняя» это ограничение SVG или просто «нет и не нужно»?

тут написано, что gpl. apt-get source xaralx прошло и вроде нет ни одного бинарного файла, на вскидку. текст gpl тоже приложен.

почитайте, вроде нормально

Промахнулся ты с ответом.

точно. но ТС все равно увидит.

> Тем паче, что на маке у cairo свои косяки.

с quartz_surface? если есть в багтрекере - плз ткните ссылкой, если нет, но желательно исправить, то также занесите в багтрекер - я попытаюсь исправить

В кореле это ограничение компенсируется наличием еффекта Ориол/Contour. Очень нужная функция. Записал в список на реализацию в sK1.

в дебе xaralx лежит в non-free, не в main.

http://packages.debian.org/search?keywords=xaralx&searchon=names&suite=all&se...