В Inkscape требует для поддержки импорта из Sketch пакет skencil, вылетает с ошибкой при импорте из sketch и не поддерживает экспорт в sketch.
Посмотрю
Перенос на конкретный пакет
Бага как бага, critical -- это если б он на старте ложился.
(In reply to comment #3) > Бага как бага, critical -- это если б он на старте ложился. Это critical, так как не соответстует условиям КД.
(In reply to comment #4) > Это critical, так как не соответстует условиям КД. (посмотрев в Product) к Sisyphus это каким боком? Задача для core dev/QA ООО или контрактная, а не майнтейнерская. Разве если packaging bug, передать в апстрим или майнтейнер участвует в разработке, но тогда нет слова "срок", что вряд ли приемлемо.
+1
-> cas@
Перевесил на Школьный и на ktirf@, critical относится к ним.
Господа, не мутите воду, багами на Школьный комплект занимается Руслан. Я могу быть только в CC, а данный конкретный баг вообще может исправить только sbolshakov@.
(In reply to comment #9) > Господа, не мутите воду, багами на Школьный комплект занимается Руслан. Я могу > быть только в CC, а данный конкретный баг вообще может исправить только sbolshakov@. Ok. Вы начальник, Вам виднее на кого вешать.
пакет skencil включается в школьный комплект с 20080311, если не раньше. если баг заключался в его отсутствии в более ранних версиях, то fixed.
Не поддерживается импорт (ошибка конвертации в скрипте) и экспорт (вообще нет в списке форматов) Sketch.
удалось выяснить, в каком пакете ошибка ?
Если формата нет в списке, значит skencil не установлен, или установлен, но не найден.
Не залезая в код Inskape, а только ориетируясь пока на Google для импорта файлов *.sk и *.sk1 нужен uniconvertor http://wiki.inkscape.org/wiki/index.php/Tools#uniconvertor. Sketch создаёт эти файлы, но не участвует в импорте Inkscape. Сам uniconvertor может конвертировать различные файлы и сам, но из командной строки. ps смотрю дальше
Извиняюсь - у нас участвует через sckonvert, входящий в пакет skencil
(In reply to comment #15) > Не залезая в код Inskape, а только ориетируясь пока на Google для импорта > файлов *.sk и *.sk1 нужен uniconvertor > http://wiki.inkscape.org/wiki/index.php/Tools#uniconvertor. Прокудин тоже говорил, что нужно его использовать. Осталось сбэкпортировать его на school-4.0 (или в branch-4.0) и обеспечить интеграцию с Inkscape.
Там этот *&^&*^&* питон, будь он не ладен. "Последний".
Мишенька, UC в обозримом будущем будет must have для импорта чужих файлов вообще, нравится тебе это или нет. Причём, он будет нужен не только Inskcape, но и Scribus. И, кстати, для импорта не столько SK, сколько CDR и прочей проприетарной фигни. Так что нравится это тебе или нет, но тебе придётся с этим жить. Да, текущая версия UC лажает с импортом SK. Это уже исправлено в транке sK1 и будет перетащено в UC при первой возможности.
(In reply to comment #19) > Мишенька, UC в обозримом будущем будет must have для импорта чужих файлов > вообще, нравится тебе это или нет. Слушай, я почти пошёл его в сизиф собирать в своё время благодаря frob :) Одна маленькая проблема, которая быстро вылезла (сразу после необходимости обновления/перелопачивания ряда модулей) -- python-2.5, на который автор успел спрыгнуть, пока разбирались с первой частью. Для мастхэвов противопоказано гоняться за последними пе... питонами. Увы, факт.
(In reply to comment #19) > Мишенька, UC в обозримом будущем будет must have для импорта чужих файлов > вообще, нравится тебе это или нет. Нам это нравится, но школьный комплект живет в обозримом прошлом, мы не можем выпустить его на свежем бранче.
> удалось выяснить, в каком пакете ошибка ? Ошибка в скрипте skconvert.py, входящем в skencil. error in line 19 Traceback (most recent call last): File "/usr/lib/skencil-0.6.17/Plugins/Filters/skloader.py", line 469, in Load funcname, args, kwargs = parse(line) SyntaxError: unexpected character Traceback (most recent call last): File "/usr/bin/skconvert", line 55, in ? main() File "/usr/bin/skconvert", line 52, in main convert(sys.argv[1], sys.argv[2]) File "/usr/bin/skconvert", line 35, in convert doc = load.load_drawing(infile) File "/usr/lib/skencil-0.6.17/Sketch/Base/load.py", line 368, in load_drawing return load_drawing_from_file(file, filename) File "/usr/lib/skencil-0.6.17/Sketch/Base/load.py", line 343, in load_drawing_ from_file doc = loader.Load() File "/usr/lib/skencil-0.6.17/Plugins/Filters/skloader.py", line 506, in Load raise SketchLoadError('%d:%s' % (num, value)) Sketch.skexceptions.SketchLoadError: 19:unexpected character
На сегодня можно предложить хак для Inkscape - в скрипте /usr/share/inkscape/extensions/sk2svg.sh строчку skconvert "$1" "$TMPSVG" > /dev/null 2>&1 || rc=1 заменить на LC_ALL=C skconvert "$1" "$TMPSVG" > /dev/null 2>&1 || rc=1
А вот и подтверждение :) http://wald.intevation.org/tracker/index.php?func=detail&aid=345&group_id=5&atid=101
(In reply to comment #23) > На сегодня можно предложить хак для Inkscape > > - в скрипте /usr/share/inkscape/extensions/sk2svg.sh > строчку > skconvert "$1" "$TMPSVG" > /dev/null 2>&1 || rc=1 > заменить на > LC_ALL=C skconvert "$1" "$TMPSVG" > /dev/null 2>&1 || rc=1 > Почему же это хак? Наверное, будет корректнее LC_NUMERIC=C
Created attachment 2579 [details] Патч для skencil Аот это уже в меньшей мере хак :)
>Почему же это хак? Наверное, будет корректнее LC_NUMERIC=C Потому, что менять надо в скриптах sketcil, а не в вызывающих скриптах :) В приложенном выше хаке, на всякий случай изменил LC_NUMERIC в аналогичных скриптах : sk2ps.py и sk2ppm.py, но я из не проверил.
Исправленно
Да? И сохранение в Sketch работает?
Выдать расширение, добавляющее экспорт в скетч при наличии юниконвертора в системе?
,----------------------------------------------------------------------------. | Выдать расширение, добавляющее экспорт в скетч при наличии юниконвертора в | | системе? | | | | [ Зажать ] | Выдать | | | | `----------------------------------------------------------------------------'
Ну раз ты, Майк, такой шутник, собирай юниконвертор :)
Вы тут не о http://sisyphus.ru/srpm/Sisyphus/uniconvertor ?
> Вы тут не о >http://sisyphus.ru/srpm/Sisyphus/uniconvertor >? Именно о нём, вернее о его бэкпортировании в школьный комплект.
(In reply to comment #32) > Ну раз ты, Майк, такой шутник, собирай юниконвертор :) Вообще-то меня frob и пинал это сделать, но основной разработчик очень вовремя тогда спрыгнул на python-2.5, а в сизифе был ещё 2.4... (In reply to comment #34) > >http://sisyphus.ru/srpm/Sisyphus/uniconvertor? > Именно о нём, вернее о его бэкпортировании в школьный комплект. Смутно припоминается, что опять же Валёк уточнял насчёт 2.4/2.5, но лучше переспросить апстрима. 2 cas: возможно, сейчас это лучше проигнорировать, а решить к M41 в рабочем порядке. Если только не "любой ценой" (ТМ). PS: хорошая иллюстрация к тому, почему питон для production противопоказан: постоянные вилки (вилы) с версиями-модулями-всеми_необходимыми_софтинками.
(In reply to comment #35) ... > > Именно о нём, вернее о его бэкпортировании в школьный комплект. > Смутно припоминается, что опять же Валёк уточнял насчёт 2.4/2.5, но лучше > переспросить апстрима. Да, вроде бы с 2.4 не собирается. > 2 cas: возможно, сейчас это лучше проигнорировать, а решить к M41 в рабочем > порядке. Если только не "любой ценой" (ТМ). > > PS: хорошая иллюстрация к тому, почему питон для production противопоказан: > постоянные вилки (вилы) с версиями-модулями-всеми_необходимыми_софтинками. Мне кажется уже стоит прекратить рассказывать какой плохой Питон и почему его нельзя использовать. Слишком уже похоже на "сосед напел", или "да 30 лет назад я программистом работал". просто вот взять и прекратить выступать об этом на каждом встречном пеньке. И иллюстрация к тому - плохая. Если бы разработчики не использовали новые конструкции, появившиеся в 2.5, проблемы бы не было.
(In reply to comment #36) > > PS: хорошая иллюстрация к тому, почему питон для production противопоказан: > > постоянные вилки (вилы) с версиями-модулями-всеми_необходимыми_софтинками. > Мне кажется уже стоит прекратить рассказывать какой плохой Питон и почему > его нельзя использовать. Слишком уже похоже на "сосед напел" Да нет, сам споткнулся. > просто вот взять и прекратить выступать об этом на каждом встречном пеньке. > И иллюстрация к тому - плохая. Если бы разработчики не использовали новые > конструкции, появившиеся в 2.5, проблемы бы не было. (пожимая плечами) Ты майнтейнер, тебе видней. Да только помимо новых конструкций -- на новые версии питона разработчиков толкает и то, что старый код на них не работает. Потому как с совместимостью проблемы в обе стороны. Всё, слез с пенька.
