[AHTOXA 15]

Наверно, чтобы не перепутать - видно соответствие po/mo с точностью до байта.

Вот чтоб не перепутать, как раз нужно избегать дублирования информации. Если хранить только *.po, то *.mo в любой момент можно получить гарантированно актуальный.

[viknn 0]

Если хранить только *.po, то *.mo в любой момент можно получить гарантированно актуальный.

Здесь получается, что каждый должен иметь редактор/транслятор переводов и желательно одной версии.

[AHTOXA 15]

Зачем?!

[zöner 0]

А правда, кто знает почему бинарные файлы kicad.mo коммитят в хранилище документации?

может потому что poedit при сохранении .ро автоматом обновляет .mo ?

наверно можно обойти фильтрами bzr (исключением .mo из репозитория). Но в таком случае при компиляции бинарников нужны утилиты gettext для конвертации РО-МО.

[mobidev 0]

Вот чтоб не перепутать, как раз нужно избегать дублирования информации. Если хранить только *.po, то *.mo в любой момент можно получить гарантированно актуальный.

Не совсем понятно в чём такая сложность хранить оба файла?

Тем более что при обновлении локального репозитория из внешнего (launchpad) грузятся только изменённые файлы.

[tema-electric 0]

При генерации перечня вместо слова "Соединители" пишет " Соединительы" ))

 

Микросхемы разделил мне ... DA отдельно DD отдельно. Может все-таки сортировать по полю "Тип", потом уже внутри по позиционке.

[AVL 0]

При генерации перечня вместо слова "Соединители" пишет " Соединительы" ))

По умолчанию для множественного числа добавляется буква "ы", например, резистор - резисторы, конденсатор - конденсаторы.

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

Для случая со словом "Соединитель" и подобные попробую добавлю тогда правило насчет мягкого знака на конце, чтобы не добавлять такие слова в словарь.

Микросхемы разделил мне ... DA отдельно DD отдельно. Может все-таки сортировать по полю "Тип", потом уже внутри по позиционке.

Нужно "поднимать" ГОСТ.

[AHTOXA 15]

Не совсем понятно в чём такая сложность хранить оба файла?

Да сложности наверное особой нету, просто неаккуратненько это как-то.

Вот вчера, собирал я кикад. lp:~kicad-gost-committers/kicad/kicad занимает 280Мб , а lp:~kicad-gost-committers/kicad/doc - 600Мб! Я чуть не закипел, пока дождался окончания закачки%)

А всё почему? Потому, что в kicad не хранят результаты компиляции (для исходных кодов программ это считается нормой). А в doc - хранят и исходники документов, и сами документы ("в чём такая сложность хранить оба файла" :) ). Вот и пухнет репозиторий, как на дрожжах.

Меня что добило: получается, что ради одного файла перевода я вынужден качать 600 метров. Разве это нормально?

(Места не жалко, жалко времени.)

[AVL 0]

Насчет бинарных файлов в хранилище. Мое мнение:

1) бинарные файлы тоже полезно хранить в хранилище с точки зрения учета и надежности хранения самих файлов. Это касается бинарных релизов и документации по крайней мере. Насчет надежности хранения говорю по крайней мере за git. bazaar скорее всего тоже хранит файлы надежно. Например git выполняет контроль на основе hash. Также, если кто-то или что-то не авторизованно в локальной копии затерло/изменило/удалило файл, то команда status показывает, что файл изменился, и можно спокойно его восстановить из хранилища.

 

2) когда принимается решение хранить бинарные файлы в хранилище, то это должно быть отдельное хранилище. Данное решение принимается осознавая нюансы, которые при этом появятся:

- хранилище будет громоздким и расти каждый раз на размер добавляемых бинарных файлов

- нет возможности выполнить diff. Единственный способ анализа изменений - по коментариям в коммитах.

- низкая скорость клонирования из сети

- низкая скорость выполнения ряда операций локально

- в какой-то момент хранилище станет на столько большим, что нужно будет отсечь старые не актуальные коммиты, либо принять решение о создании нового хранилища, а предыдущее хранилище использовать как архив и больше в него не коммитить

- ну и наверно еще какие-то нюансы

 

3) плохо мешать исходники программы с бинарными файлами, особенно большого размера, например релизами программы (в каких-то ситуациях могут быть исключения, особенно, если файлы небольшого размера, меняются редко и в них есть особая необходимость):

- если уж в случае хранилища для бинарных файлов можно смириться, чтобы работало медленно, то для хранилища с исходниками программы с этим нельзя смириться, где выполняются рутиные операции (log, commit, diff, merge...)

- в случае коммерческих проектов важно хранить исходники программы и ее бинарные релизы в разных местах с разными правами доступа (ну в случае KiCad это не имеет силы)

 

P.S.: насчет хранения бинарных файлов kicad.mo пока сомневаюсь, что их вообще нужно хранить, если есть возможность сделать их генерацию в момент сборки.

Изменено 14 июня, 2013 пользователем AVL

[AVL 0]

При генерации перечня вместо слова "Соединители" пишет " Соединительы" ))

Добавил обработку мягкого знака в конце слов. Такие слова теперь не нужно будет харкодить в словаре словоформ.

 

Актуальная ревизия 4148 (также начата поддержка выбора режима генерации между русским и английским языками).

[Aldan 0]

Переписал свой скрипт, теперь он имеет графический пользовательский интерфейс и с ним можно работать как с обычной программой.

Константин, у меня наконец-то появилось время попробовать Ваш скрипт. Скачал с https://launchpad.net/kicadbom2spec свежую версию — 2.3 и стал все делать по описанию. Хочу еще раз отметить добротность описания — все понятно даже для самого-самого начинающего.

Во время установки всех компонентов все происходило именно так, как описано. Однако, результат отличается: не удается запустить kicadbom2spec.pyw, т. е. при двойном клике по файлу на долю секунды возникает значок начавшегося процесса и все...

Константин, какие еще действия нужно предпринять, чтобы получить результат?

Имеющиеся различия у меня с тем, что в описании:

- у меня не ХР, а Вин7х64,

- загрузился python-3.3.2, а не 2.7.4, как в описании. (потом переставил на python-2.7.5 и все равно не запускается)

Заодно еще доп. Вопрос: какой шрифт лучше opengostfont-otf-0.3 или opengostfont-ttf-0.3 и для какого случая? Стоит ли установить все шрифты сразу OpenGostTypeA-Regular.otf, OpenGostTypeB-Regular.otf, OpenGostTypeA-Regular.ttf, OpenGostTypeB-Regular.ttf? Какие шрифты стоят у Вас?

Изменено 15 июня, 2013 пользователем Aldan

[baranovskiykonstantin 0]

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

Нужно открыть с помощью любого текстового редактора файл kicadbom2spec.pyw и в первой строке явно указать версию питона:

было:
#!/usr/bin/env python
стало:
#!/usr/bin/env python2

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

 

На счет шрифтов. Для оформления я использовал один шрифт - OpenGostTypeB-Regular.ttf, его будет достаточно. OTF или TTF - дело вкуса. OpenTypeFont (OTF) новее чем TrueTypeFont (TTF) и поддерживает больше функций и разных примочек. Но это скорее важно для дизайнеров шрифтов, а конечный пользователь разницы не заметит. TTF выбрал в сило того, что на Windows используются шрифты, в основном, этого типа.

Изменено 15 июня, 2013 пользователем Барановский Константин

[Aldan 0]

Aldan если третий питон не удален из системы, то, возможно, скрипт пытается запуститься с его помощью.

Это странно, если он не удален из системы, т.к. я проделал стандартную процедуру по деинсталляции после чего удалил вручную папку с небольшими остатками. Может быть есть какой-то простой способ убедиться в том, что третий питон удален?

Aldan Нужно открыть с помощью любого текстового редактора файл kicadbom2spec.pyw и в первой строке явно указать версию питона

Добавил двоечку, сохранил, запустил.., не пошло. Константин, а в каком направлении думать, ведь этот скрипт работал у других, так? Так почему мой случай требует какого-то особого подхода?

И еще, Константин, а не может odfpy, который был установлен при третьем питоне мешаться? Вроде глупая мысль, но решил спросить? Если что, то просто повторить процесс установки, но при втором питоне?

-----------

Константин, моя догадка сработала: я переустановил odfpy и скрипт стал запускаться, причем и без дополнительной двоечки. Так что все беды были от того, что я не зная засады от третьего питона установил именно его, думая, что он самый-самый :) Чуть попозже буду тестировать дальше.

-=-=-=-=-=-=-=-=-=-=-=-

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

Прежде всего, вспоминая ситуацию когда я не мог запустить скрипт, предлагаю во избежание ее повторения создать ехе-файл, запуск которого инициирует последовательную установку всех компонентов — python, odfpy и шрифт — автоматически.

В развитие этого предложения можно питон не устанавливать, а использовать тот, что в ЛибреОфисе. Это не будет интеграцией скрипта в Кикад, но будет дружественной автоматизацией процесса установки.

 

Порадовало Ваше изящное решение брать информацию о компонентах из схемы. Действительно, все схемные элементы имеют обозначения согласно ГОСТ, что позволяет однозначно определить к какой группе они относятся. Я в своей библиотеке сгруппировал компоненты при помощи префиксов по этому же самому ГОСТ и предлагал AVL использовать их для автозаполнения в GOST-doc-gen, а Вы сделали все еще изящнее — точно такую же информацию взяли прямо из схемы. В результате спецификация в Вашем скрипте получается по нажатию всего лишь одной кнопки — это здорово. Однако, непонятно, почему же Вы не пошли дальше и не ввели названия групп компонентов? Ведь С — это конденсаторы, R — резисторы и т. д., так почему же не ввести автозаполнение наименования таких групп?

 

В вашем скрипте, как и в GOST-doc-gen не решена проблема отбрасывания надписи «схема электрическая принципиальная». На мой взгляд автодописывание «Ф», «Гн», «Ом» нужно сделать отключаемым т. к. не всегда это к месту. Неплохо бы ввести лист регистрации изменений.

 

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

 

Обнаружилась странность с выводом на печать: я сформировал документ на 3 листах и попробовал вывести его на виртуальный pdf-принтер, так вот, первый лист почему-то бесследно теряется и не хочет распечатываться.

 

Словом, Ваш скрипт — огромный шаг от ВОМ к цивилизованной текстовой документации, но расти еще есть куда и даже очень.

Изменено 15 июня, 2013 пользователем Aldan

[AVL 0]

Завершен переход на новые форматки Константина Барановского. Ветка lp:~kicad-gost-committers/kicad/GOST-doc-gen-new-templates закрыта.

Актуальная ревизия 4152.

 

Пока не предусмотрена автоматическая установка шрифтов (нужно думать как вообще это сделать).

Комментарий Константина по ручной установке шрифтов:

Шрифты установить можно простым копированием файлов в:

~/.fonts/ - для Linux

C:\WINDOWS\Fonts\ - для windows

как быть с OSX не знаю.

Копировать нужно только один файл, а именно, файл из дерева исходников: kicad_src_root/eeschema/GOST-doc-gen/templates/OpenGostTypeB-Regular.ttf

[Aldan 0]

Актуальная ревизия 4152.

AVL, я решил глянуть как продвигается дело с GOST-doc-gen для чего установил самую свежую из доступных сборок kicad_gost_commiters_testing_bzr4146, сформировал перечень и обнаружил подтверждение пословице «быстро сказка сказывается, да не быстро дело делается», что и ожидаемо, т. к. времени прошло немного. По этой причине я не буду касаться того, что мы уже обсуждали, а сделаю лишь некоторое дополнение.

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

Ранее я писал, что библиотека mixture.lib содержит обобщенные названия компонентов, которые в конкретной схеме приобретают совершенно конкретные значения.

Как образовалось наименование «с_сар»? Изначально в кикадовских библиотеках были графические обозначения двух типов конденсаторов постоянной емкости: «сар» — конденсатор и «сарр» — конденсатор поляризованный, т. е. электролитический. Позже, когда я всем компонентам раздал префиксы по ГОСТ из этих двух обозначений «сар» и «сарр» получились «с_сар» и «с_сарр». Таким образом, префикс «с» говорит о том, что это конденсаторы, а «сар» и «сарр» позволяет отличить обычный конденсатор от электролитического. Все это важно только до момента выбора компонента из библиотеки. Далее, в самой схеме, различение обычного конденсатора от электролитического обеспечивает его графическое изображение и никакие «сар» и «сарр» не применяются и на схеме Вы их не найдете.

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

Поскольку перечень формируется по конкретной схеме на которой нет никаких «с_сар», непонятно откуда же они и для чего в нем появляются? То же самое происходит и со всеми другими компонентами из библиотеки mixture.lib.

Для примера, в скрипте Константина Барановского используется информация прямо из файла схемы и по этой причине такие накладки исключены. Может быть и Вам сделать так же?

И еще, повторяю свою просьбу о написании хоть самого-самого краткого руководства пользователя GOST-doc-gen, чтобы понимать тонкости работы и делать все правильно.