Я пробовал редактировать сгенеренный скриптом файл *.ods и нашел, что это не такое уж утомительное занятие. Однако, с редактором полей элементов все будет гораздо шоколаднее

Как я уже написал, игры с диапазоном печати ни к чему не привели. Тогда я взял в руки бубен и решил все переустановить еще раз, а то ведь то питон правил, а потом отдельно odfpy. Распечатке первых листов это не помогло, а вот проект с названием из трех букв стал конвертироваться без проблем. Все же одной проблемой меньше

Что касается пропадения нескольких горизонтальных разделительных линий, то это оказался глюк ЛибреОфиса при предварительном просмотре перед печатью. Сама печать проходит без этих артефактов.

Я специально зарегистрировался на https://launchpad.net и зашел к Вам на https://launchpad.net/kicadbom2spec где нашел Ваш адрес электронной почты. Выслал на него часть проекта полуторагодовалой давности. Предлагаю дальнейшее общение продолжить по переписке. Считайте, что я обратился к Вам не через форум, а прямо на launchpad. Так будет гораздо удобнее.

Сделал хоть какую-то документацию для менеджера компонентов и GOST-doc-gen. Пока без описания работы с исполнениями и комплектами.

Ревизия 445 ветки lp:~kicad-gost-committers/kicad/doc

doc/help/ru/GOST_Tools.pdf
doc/help/ru/docs_src/eeschema/GOST_Tools.odt

ссылка для скачивания

Это делается оптимизация атрибута Type. Оптимизация заключается в том, что если по факту после работы с менеджером компонентов атрибут Type оказывается пустым, то он удаляется из-за ненадобности из компонента. Причем в EESchema используется такая же логика. Если пользовательский атрибут становится равен пустой строке, то атрибут удаляется самой EESchema.

По поводу автоматической очистки поля Value пока не вижу красивого решения. Надо еще думать.
А вот по поводу принудительного создания Type и отмены его оптимизации согласен. Здесь получаем преимущества:
1) обеспечиваем прозрачность работы с полем Тип
2) даем возможность делать видимым атрибут Тип (в EEShema не предусмотрена возможность делать видимым атрибут Chip Name)

Таким образом, будем действовать поэтапно.
На данном этапе предлагаю пока только сделать добавление атрибута Type равное Chip Name, если до этого атрибут Type отсутствовал.
В этом случае в целом не ломаем все, что было раньше (схемы ранее введенные / импортированные из P-Cad как работали с GOST-doc-gen так и продолжат работать).
Но зато получаем преимущества в приведенных выше пунктах 1 и 2.

Возможно здесь есть неоднозначность поведения EESchema? У меня прям сейчас схема открыта, и в ней компонен есть, самый первый попавшийся взял, и там Type пустая стока. Хм, попробовал ручками сделать это, и не получилось. Попробовал через менеджер очистить. Получилось, и EESchema не ругается. Вобщем это ее дурацкая внутренняя проверка, которая где-то отключается. Читать и сохранять пустые поля из файла она умеет.


Оно должно очищаться только в случае, если совпадает с ChipName. Это означает, что компонент только вставлен в схему и пользователь еще не определил значение. На данный момент целесообразно было бы делать это только для новых компонентов, в которых есть поля для GOST-Tools.

Может быть не отказываться от автоудаления пустых полей в компонентах, хотя бы со стороны GOST-Tools? Это конечно раздует файл, но зато при редактировании компонента, можно ручками уже набрать нужное значение, если лень лезть в GOST-Tools.

В EESchema оно у меня ругнулось, что ввожу пустое значение и предупредило, что если все-таки введу пустое значение, то атрибут будет удален.
Также странная ситуация с Вашим примером, в котором поле Value в каком-то случае вообще не отображалось в свойствах компонента.
Ну здесь проще сделать так, как это ожидает EESchema получить. В случае пустой строки GOST-doc-gen сделаю, чтобы не пустую строку обратно в схему сохранял, а символ "~".
Это пока касается атрибутов Value и Type.

А как менеджер компонентов сможет различить где старые, а где новые? И что такое старые, что такое новые?

Я вот думаю, а что нам мешает (только на уровне кода EESchema) в момент добавления сделать все как надо? А именно, при добавлении нового компонента прямо в коде EESchema сделать, чтобы атрибут Value по умолчанию устанавливался в "~", и по умолчанию сделать чтобы автоматом добавлялся атрибут Type равный значению Chip Name?
При этом даже совместимость ни с lp:kicad ни с существующими схемами никак не пострадает.
Данная мера после ее принятия наладила бы нормальный режим работы при разработке новых схем и редактировании имеющихся схем в случае редактирования атрибутов через GUI EESchema.
Есть ли у такой меры подводные камни?

Первое предложение не понял. Имеется в виду, чтобы все 8 атрибутов, которые используются менеджером компонентов создавать безусловно, даже если они пустые?
Пока уверенность есть, что нужны всегда поля Value и Type. Насчет остальных полей и так и так вроде хорошо. Надо тогда продумать какие плюсы и минусы у каждого из подходов и выбрать тот, у которого плюсов больше.

Если есть хотя бы одно поле GOST-Tools, а список Вы ранее приводили, значит новый. В простейшем случае новый компонент, это тот у которого есть поле Type. Если принять во внимание Ваши прежние посты, в которых говорится, что поле Type обязательное и должно быть заполнено, т.к. в спецификации от него многое зависит, то можно так и сделать.


Были бы, если бы библиотечный компонент содержал предопределенное Value. Сейчас попробовал сделать это. Переименовал поле Value и, в итоге, он сохранился уже по переименованному полю Value.
Сделал еще финт ушами, поправил прям в библиотечном файле через текстовый редактор ChipName и Value. В итоге при просмотре через Viewer отображается все нормально Резистор такой то, сопротивление 1 кОм, однако после добавления на схему он заменяет поле Value на ChipName. Вывод: если сменится подход в самом редакторе библиотек, то возможно затирание предопределенного значнения. Поэтому нужна проверка ChipName==Value.



Пустое поле под документацию лежит и не жужжит. Они его застолбили, и возможная причина тому, что всего полей может быть 11. Из них 4 уже заняты. Так написано в описании к форматам файлов. Т.е. если кто-то еще захочет добавить какие-то свои поля, то они просто могут не сохраниться или наоборот они будут, а GOST-Tools какие-то свои поля не сохранит. Возможно сейчас формат поменялся. Но раньше такое ограничение было.

С учетом имеющейся картины, появилась еще идея алгоритма №2. Однако ни о какой прозрачности для пользователя при таком подходе речи не идет. Но зато судя по анализу всех рассматриваемых тестовых случаев, работает!

На этапе конвертации pcad2kicad сделаю следующую обработку:

Тогда это позволит применить алгоритм №2 (см. ниже).

Тестируемые случаи с учетом доработки в конвертере pcad2kicad

импортированные схемы из P-Cad:
1) ChipName = "SN74HC00D", Type = "SN74HC00D", Value = "~"
2) ChipName = "К73-17", Type = "К73-17", Value = "0,1 мкФ"
3) ChipName = "7400", Type = "SN74HC00D", Value = "~"
4) ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"

оригинальные схемы KiCad сразу после добавления компонента в схему (без каких пока еще корректировок полей)
5) ChipName = "7400", Value = "7400"
6) ChipName = "C", Value = "C"

оригинальные схемы KiCad при использовании в режиме навязанного кривого подхода
7) ChipName = "7400", Value = "SN74HC00D"
8) ChipName = "C", Value = "0,1 мкФ"

оригинальные схемы KiCad при использовании в режиме выправленного подхода
9) ChipName = "7400", Type = "SN74HC00D", Value = "~"
10) ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"

тестируемый алгоритм №2 под кодовым названием "взрыв мозга"
Здесь для понимания:
а) имена атрибутов на английском (ChipName, Type, Value) - это те атрибуты, которые хранятся в схеме.
б) имена полей на русском (Тип, Номинал) - это те поля, которые отображаются/редактируются в менеджере компонентов, и которые в результате поступают на вход генератора GOST-doc-gen.

Результирующие поля после обработки алгоритмом
1) [ChipName = "SN74HC00D", Type = "SN74HC00D", Value = "~"] => [Тип = "SN74HC00D", Номинал = "~"]: OK
2) [ChipName = "К73-17", Type = "К73-17", Value = "0,1 мкФ"] => [Тип = "К73-17", Номинал = "0,1 мкФ"]: OK
3,9) [ChipName = "7400", Type = "SN74HC00D", Value = "~"] => [Тип = "SN74HC00D", Номинал = "~"]: OK
4,10) [ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"] => [Тип = "К73-17", Номинал = "0,1 мкФ"]: OK
5) [ChipName = "7400", Value = "7400"] => [Тип = "7400", Номинал = "~"]: OK
6) [ChipName = "C", Value = "C"] => [Тип = "C", Номинал = "~"]: OK
7) [ChipName = "7400", Value = "SN74HC00D"] => [Тип = "SN74HC00D", Номинал = "~"]: OK
8) [ChipName = "C", Value = "0,1 мкФ"] => [Тип = "0,1 мкФ", Номинал = "~"]: FAILED
Однако в пунте 8 в любом случае, чтобы сформировать КД нужно также указать какого же все-таки типа конденсатор. После добавления типа (через схему добавить и назначить атрибут Type, либо задать поле Тип через менеджер компонентов) будем иметь следующий тестовый случай:
8a) ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"
Тогда результирующие поля для данного тестового случая после обработки алгоритмом будут:
8a) [ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"] => [Тип = "К73-17", Номинал = "0,1 мкФ"]: OK!

Да, реально взрыв мозга. Зачем это надо?
Вы правда собираете генерировать перечень, в котором будет просто указана емкость 0.1 мкФ? Или все же у Вас это запись для примера?

Еще реторический вопрос: чего всегда больше в проекте? Пассива или микросхем? отсюда приоритет можно расставить поля Type или Value.

Там где нельзя определить тип автоматически, лучше заполнить его Type="Не определен" и подсветить такие компоненты красным цветом.

Это в продолжение для "Предлагаю решение, которое скорее всего устроит всех..." Я пока только не знаю кто такие все
По крайней мере для всех тестовых ситуаций, которые взял в рассмотрение (может еще какие-то еcть?), алгоритм №2 выглядит, что работает.
Но еще подумав, понял, что сделать нормальный ввод поля Тип с помощью менеджера компонентов для тестового случая 8 - это еще одна головоломка и добавление костылей в код.

Приведенный анализ для алгоритма №2 наглядно показывает к какой запутанной ситуации привел французский подход.

Нет, я не собираюсь генерировать перечень, в котором будет просто указана емкость 0.1 мкФ
Тестовый случай 8 - это промежуточное состояние схемы до того как она будет доведена до состояния 8а.
Если я правильно понял, есть те, кто заполняет только атрибут Value. Это как раз случаи 7 и 8. Теперь, если эти люди хотят сформировать КД, то для случая 8 им нужно сделать так, чтобы появился атрибут с заполненным типом компонента. Это можно сделать либо посредством добавления/заполнения атрибута Type в свойствах компонента через GUI EESchema, либо, если прикрутить дополнительные костыли, то это будет возможно в менеджере компонентов.

Да у меня уже такое чувство, что только внедрение искусственного интеллекта в менеджер компонентов может как-то сдвинет ситуацию

Сообщение отредактировал AVL - Jun 23 2013, 15:59

На тот момент было два человека Я и Aldan.

Aldan смущала склейка ChipName + Value в документации. Но это так или иначе вылечится.
Меня смущала непрозрачность, связанная с полями Type и Value. И до сих пор смущает. Повторюсь. Пользователь видит некие значения в менеджере GOST-Tools, и эти значения однозначно должны находится в соответствующих полях внутри компонента. В предложенном втором алгоритме нарушается эта идеология. Появляется Русский подход



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

Я лично отдаю предпочтение прозрачному простому подходу, пусть даже за счет доработок в самой EESchema.
А вот алгоритм №2, хоть и справляется успешно с интерпретацией запутанного кома проблем, но пусть будет наглядным примером сути обсуждаемой ситуации.
Надеюсь пользователи посмотрят на него, ужаснутся, и не будут настаивать идти таким путем

За прозрачность . Александр, на следующей неделе (во второй половине) буду заполнять схему примерно из 250 элементов с целью получить перечень. Конденсаторы и резисторы в большинстве своем там уже с новыми полями. Если будут какие-то решения конечные по алгоритму, и желание протестировать его в боевых условиях, я готов.

С учетом имеющейся картины, даю обновление действий по первому этапу.

I) На этапе конвертации pcad2kicad сделать следующую обработку:

Данная мера позволит уйти от необходимости чтения атрибута Chip Name в менеджере компонентов.

II) сделать принудительное добавление атрибута Type равный "~", если до этого атрибут Type отсутствовал.

Итоговые преимущества:
1) обеспечиваем прозрачность работы с полем Тип
2) даем возможность делать видимым атрибут Type (в EEShema не предусмотрена возможность делать видимым атрибут Chip Name)
3) уход от необходимости чтения атрибута Chip Name менеджером компонентов ("Aldan смущала склейка ChipName + Value в документации." Теперь явной такой склейки не будет. Однако, если кто-то так и будет продолжать вбивать значение типа компонента в атрибут Value, то GOST-doc-gen, как я объяснял, не будет корректно генерировать КД в целом, не смотря на то, что отдельно взятые строчки в документах будут выглядеть корректно).

Реализовал данную логику в ревизии 4162.
Однако, стало видно недостаток. Из-за того, что убрал чтение Chip Name менеджером компонентов, теперь пострадали компоненты-псевдонимы. Таких компонентов-псевдонимов достаточно много даже в стандартных библиотеках KiCad.
Вернул начальную инициализацию атрибута Type значением из Chip Name. Соответственно доработку пункта I) для pcad2kicad тоже отменил.

Если вдруг кому-то все-таки захочется атрибуты Type затереть пустыми строками (я правда так и не в состоянии понять зачем так делать), то это можно сделать в менеджере компонентов групповой операцией: выделить все компоненты через SHIFT и стереть содержимое поля Тип.

Таким образом, нововведение заключается в следующем:
1) при открытии менеджера компонентов, если у компонента нет атрибута Type, то он принудительно создается, и ему делается начальное присвоение значения атрибута Chip Name. С этого момента атрибут Type больше никогда не удаляется менеджером компонентов, даже если поле Тип было очищено. Также с этого момента поле Тип полностью прозрачно по отношению к атрибуту Type
2) атрибут Value/Type теперь становится равен "~", если поле Номинал/Тип было стерто в менеджере компонентов

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

AVL. Собрал 62ю ревизию, проверил. Да, все работает так, как Вы написали. Автоматом появляется поле Type. Поле Value очистить не долго. Благо есть групповое выделение. Айс
Посмотрел CvPCB. Длинновата запись, но это лучше чем было до этого.