Барановский Константин, faa


Как у разработчиков хотел спросить а сложно сделать подсветку дорожек в eeshema ?.... или это уже есть в eeshema и я просто не внимателен, в gshem gEDA это реализовано двумя кликами по wire. Или в сложных схемах проще искать поиском?

Попробовал открыл эл. схему, очень понравилось. Но, при использовании этой сборки, файл в pcbnew почему-то открылся без записей в штампе, хотя в "нстройка страницы" они остались.
Кстати, линии пока остались одной толщины.

Спасибо! , это я виноват не снял галку с границ.... А можно туда добавить утилиту чтобы.... модельки посадить?
Ща напишу у себя на сайте src.lgg.ru краткую инструкция, также советую Вам перенести содержание EXAMPLE в README ... можете воспользоваться разметкой markdown тогда будет README.md

Это надо автора пытать
А то даже Уэйн уже на крыло встал - готов запостить, а там еще есть что править (под вин без бубна не собралось).


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

Над этим пока работаю.
По прикрепленной картинке я заметил, что не подхватились drill-файлы, они должны лежать в той же папке, где и исходные svg, и с аналогичным префиксом (т.е. "light_wisp.drl" и/или "light_wisp-NPTH.drl"). Если отверстия сильно смещены, но нужны установить точку начала координат для drill/pos файлов в верхний левый угол платы. Также может быть небольшое смещение из-за ширины линий границы.

Все попробовал!!! Работает..., советую поговорить с
Miguel Angel Ajo Pelayo miguelangel@nbee.es , который ответственен за python скриптование может он расскажет как Вашу разработку встроить в pcbnew ... хотя бы так.... а то там работа с 3д модельками вообще не теплится.....ну судя по рассылке)))

Aldan:
Попробовал открыл эл. схему, очень понравилось. Но, при использовании этой сборки, файл в pcbnew почему-то открылся без записей в штампе, хотя в "нстройка страницы" они остались.
Кстати, линии пока остались одной толщины.

Прошу сильно не пинать, недоглядел в сторону PCBnew. Прикрепленный патч исправит отображение текста в основной надписи.
Чтобы увидеть разные по толщине линии в PCBnew нужно в меню "Размеры -> Текст и графика" в группе "Общие" установить "Размер пера по умолчанию" побольше, например 0.25 мм.

break:
Ещё бы хорошо удвоенную тильду изображать именно как тильду, а не как тут же отключенное надчёркивание.

Тильду уже видно, вот только она отображается не по центру, а смещена в врех:


Когда удастся поставить ее на место, выложу патч.

И еще тогда будет просьба:
Выложить консолидированный патч к текущей bzr-ревизии lp:kicad со всеми Вашими изменениями, касающимися ГОСТ.

Чтобы накатить и подготовить сборки для тестирования.
И при положительном заключении местных гуру закоммитить его на lp:kicad.

С каждой новой версией Eeschema приобретает всё больше глюков, при этом старые не исправляются.
Теперь ещё при перетаскивании проводников за место стыка (поворот, разветвление), проводники рассоединяются. То есть перетаскивается только одна часть проводника.

break:
Теперь ещё при перетаскивании проводников за место стыка (поворот, разветвление), проводники рассоединяются. То есть перетаскивается только одна часть проводника.

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

Нет возможности редактировать сообщения, так что пришлось создать новое...

Удалось победить тильду путем редактирования шрифта (она там, почему-то, была задрана вверх). Но есть одна особенность, которую придется учитывать - символ тильды распознается в первую очередь, а надчеркивание во вторую. Таким образом если, к примеру, имеется текст "~~~text", то он отобразится следующим образом: первые два знака будут приняты как "~", а третий как начало надчеркивания. То есть получить полностью надчеркнутый текст, который начинается с тильды, не выйдет - символ тильды останется без надчеркивания. Во всех остальных случаях она ведет себя как обычный символ.

Вот пример текста, для наглядности:


faa:
И еще тогда будет просьба:
Выложить консолидированный патч к текущей bzr-ревизии lp:kicad со всеми Вашими изменениями, касающимися ГОСТ.

В приложении патч с последними изменениями.

Да, теперь линии получились разной толщины, ндравицца
--------
faa, как-то неудобно просить так часто новую сборку, но Жан Пьер выкатил еще более стабильную на свой фтп - KiCad_stable-2013.03.04-BZR3984 http://iut-tice.ujf-grenoble.fr/cao/
Так может быть украсить ей папочку "release"? ftp://ftp.kicad.ru/pub/kicad/release/

Кокос не растет:


UPD:настоятельно прошу тщательнее проверять патчи перед публикацией.
Штатных тестеров нет, а разгребать чужие "косяки" времени особо нет (в своих бы разобраться).

UPD2:

Исправлюсь. Напутал с верхним дополнительным полем...

Хотелось бы узнать мнение сообщества, нужно ли верхнее поле в расширенном варианте?

Может стоит оставить только поле для децимального номера?
Я, например, ни разу не встречал схемы (да и любого другого чертежа) с верхними дополнительными полями. А ведь место на чертеже они занимают (особенно заметно на А4).
Если хотя бы один из пользователей нуждается в этих дополнительных полях - вопрос снимаю и замолкаю.

В приложении два патча:
1. gost.patch.zip - c расширенным верхним полем (как сейчас)
2. gost_v2.patch.zip - c обычным верхним полем (только поле для децимального номера)

Оба патча проверил, собралось без ошибок.

Поля нужны.

Хор.



Украсим в ближайшее время.

faa, а может быть эту стаб. сборку сделать с последними патчами, если с ними теперь все в порядке?

Если соберется корректно, то включу.
Заодно потестим

Похоже, что нынешняя стабильная сборка тоже не последняя на ближайшие дни, т.к. Жан Пьер все еще не сбавил обороты в деле вылавливания багов: "Pcbnew: fix Bug #1148785 (pcbnew crashes when using only one layer in autorouter )" - revision 3985. Так что, может быть стоит выждать еще несколько дней, а потом уж собрать самую-самую стабильную сборку.

faa, нужна ваша помощь!
Захотелось мне пощупать скрипты на питоне. Собираю bzr3980 в Ubuntu 12.10 (32bit), останавливается на этапе "Linking CXX shared module _pcbnew.so". Полный лог прикрепил.
Параметры сборки: cmake -DwxUSE_UNICODE=ON -DKICAD_GOST=ON -DKICAD_TESTING_VERSION=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DUSE_NEW_PCBNEW_LOAD=ON -DUSE_NEW_PCBNEW_SAVE=ON -DUSE_IMAGES_IN_MENUS=ON -DMAINTAIN_PNGS=ON -DCMAKE_INSTALL_PREFIX=/usr ../
Установлены:
swig2.0.7, python2.7, python3.2

ЧЯДНТ?

собирал ok для win32, swig2.0.9, python2.7, wx2.9.4, gcc 4.7.2

cmake -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE=Release -DwxWidgets_ROOT_DIR=c:/msys/1.0/local -DKICAD_GOST=ON -DKICAD_TESTING_
VERSION=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DPYTHON_EXECUTABLE=c:/Python27/python.exe -DSWIG_EXECUTABLE=c:/
msys/1.0/home/vik/swig/swig.exe -DSWIG_DIR=c:/msys/1.0/home/vik/swig -DCMAKE_INSTALL_PREFIX=../../../kicad_ins_py ../../

собралось на ubuntu 12.04 х86_64.
добавил
sudo apt-get install swig python-dev
собирал скриптом:

Принимайте.
Можно тестировать стабильную версию с новым ГОСТ-патчем от К.Барановского

faa, премного благодарен!
Сборка работает, патч тоже. Все пока симпатично. Только один маленький вопрос: Жан Пьер на мой взгляд еще не выкатил наипоследнейшую из наистабильнейших сборок этой недели а только сделал очередной фикс. Если мы заглянем в свойства нынешней сборки, то увидим, что у нее стоит "testing". Правильно ли я понимаю, что теперь, как в старые добрые времена, тестовая сборка с номером как у стабильной имеет одинаковый код байт в байт? Т.е. не стоит смущаться надписью "testing"?
Хотя, я почти уверен, что Жан Пьер в ближайшие дни еще выкатит самую наистабильную версию и тогда можно будет собрать непоколебимую сборку.

Я оставил тестинг из соображений, что тут применен патч К.Барановского (который и надо тестировать).
И основа - она та же, что и у стабильной. Если убрать указанный патч, то будет почти байт в байт
(добавлены/изменены "горячие" клавиши для ширины дорожки, исправлен вывод дуг на слое чертежа в DXF, исправлены 2 ошибки форматов сообщений).

Всем доброго времени суток =)

Решил сделать свежий порт KiCAD для FreeBSD, т.к. текущий имеет версию аж 2010-05-05-BZR2356. А я смотрю проект не стоит на месте и к нему присоеденились «наши» =) И даже свою сборку организовали, которой бы тоже порт не помешал...

Электронными поделками я занимаюсь весьма эпизодически. По этой причине эпизодически обращаюсь к CAD системам. До того как обратил внимание на KiCAD, я пользовался Eagle. И вот решил кое-что смастерить, глянул — Eagle из портов пропал =( Тут-то на KiCAD и наткнулся. В принципе для моей поделки достаточно и старой версии, но хочется помочь проекту.

На этом присказака заканчивается. Начинается сказка.

Сборка у меня обломалась с первого же .cpp файла:



Нарвался на ошибку препроцессора. Вот только совсем не пойму откуда она такая вылезла. Тот же результат получается даже в случае полной замены содержимого файла pinorient_right.cpp на что-нибудь совершенно иное. Пробовал разные версии gcc — результат одинаков.

Собственно вопрос: не нарывался ли кто-нибудь на такое поведение при сборке? А если да, до как решалось?

Ну и в заключение хотелось бы сказать что GOST сборке не помешал бы собственный сайт. Чтобы сложить в одно место сборку, библиотеки, информацию для русских пользователей, а так же для разработчиков. Глядишь интерес к проекту повысится, а то непосвящённому сложно собирать крупицы информации с разных форумов. У меня имеется собственный сервер в датацентре Ростелекома, где я предоставляю услуги хостинга. Могу предоставить место для такого сайта бесплатно.


Похоже не указана линковка библиотеки libpython.
Если не затруднит, покажите пожалуйста лог сборки с параметром cmake:

Ругается он на какую-то из опций командной строки. Вероятно на одну из -D. Я бы выполнял эту команду из консоли постепенно убирая по одной опции и нашел виноватую. Дальше будет видно, куда копать.


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

Проблема проявляется при вызове pcbnew <имя_файла.brd>, т.е. при вызове с загрузкой файла из текущей директории. В ReadProjectConfig() передается имя файла проекта <имя_файла.pro>, которое потом внутри ReCreatePrjConfig() передается конструктору wxFileConfig. Так вот согласно описанию, wxFileConfig при этом ищет файл ~/.имя_файла.pro и, естественно, не находит, после чего ReadProjectConfig() смело загружает kicad.pro из директории templates. Если при вызове pcbnew указать полный (абсолютный) путь к brd-файлу, то wxFileConfig использует этот абсолютный путь и файл находит. При этом eeschema при точно таком же вызове на пути к ReadProjectConfig() добавляет полный путь к имени файла проекта. Вот тебе и "повторное использование кода". Попробую сегодня найти то дивное место, где добавляется путь в eeshema и сделать патч с таким же действием для pcbnew. Или кто-то может это сделать быстрее?

Спасибо всем за проявленный интерес к моей проблеме.



Вывод команд cmake и make в приложении.

В eeschema при вызове ERC каждый раз создаётся новое окошко. Наверное при наличии уже открытого окна ERC нужно активизировать его?

И попутно маленький вопрос: можно ли как-нибудь в схематике отключить отображение кружочка в месте соединения ножки компонента с проводником?

--------
Ещё вопросы по eeschema:
1. Почему у меня нет пунктов чертить в PS/SVG/DXF? (Есть только "Чертить" и "Чертить в буфер обмена".)
2. Зачем нужны пункты "Сохранить настройки"/"Загрузить настройки"? Вроде бы как и без них всё сохраняется/восстанавливается

Барановский Константин
В выводе cmake имеется странная строчка:
-- Found PythonLibs: /usr/lib/python3.2/config/libpython3.2.so (found version "2.7.3")
Нашёл он либу версии 3.2, а опредил её версию как 2.7.
В версии 2.7 необходимые функции имеются, я проверил у себя. А в версии 3.2 — отсутствуют. У меня 3.3 и я проверял на ней, но в пределах мажорной ветки существует бинарная совместимость, т.ч. в 3.2 они тоже отсутствуют.

Полагаю в системе имеется Python двух версий. 3.2 и 2.7. Но в cборочных скриптах не указана небходимая версия. Её надо просто указать.

Приложить патч не получилось, поэтому выкладываю его сюда...



Точно. Сам не заметил что "-D-pthread" несколько выбивается из синтаксиса. Благодарю! =)

Так и есть.


С патчем все собралось без ошибок.
Спасибо! Большое при большое))


Нашел две ошибки касающиеся недавно добавленной тильды:
1) при вводе нескольких подряд символов '~' неверно определялась длинна текста;
2) при экспорте в DXF не верно отображалась та самая тильда.

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

Я это и имел в виду. Таким образом, если не заглядывать в «информацию о версии», то можно смело считать, что работаешь в полноценной стабильной сборке.
Я спрашивал об этом по той причине, что после перехода на bzr некоторое время номера тестовых сборок сильно отличались от номеров стабильных, а теперь вроде бы все вернулось к номерному единству.
Единственное отличие пока состоит в том, что раньше Жан Пьер несколько раз объявлял релиз-кандидат и все спешили подчистить свои косяки до выхода финальной версии. А сейчас, никаких «кандидатов», а просто несколько раз за короткое время выкладывается «стабильная версия», которая после нескольких итераций переходит в действительно стабильную.
Но это все так просто, заметки на полях...

А теперь небольшие наблюдения за поведением форматок в данной сборке - bzr3985-win32 newgost. Помнится, обычно вопросы возникали с форматкой А4. Для тестирования я создал новый проект из пары компонентов и нескольких проводников, чтобы можно было пробежаться по основной технологической цепочке. И вот какие наблюдения.
Изначально при создании проекта форматка А4 стоит вертикально, как и положено. Более того, при печати теперь не приходится все время переводить в книжную ориентацию, т. к. это наконец-то делается автоматически (когда это исправилось не знаю, т. к. долго работал на прежней стабильной сборке и в тестовые не лез).
При новом открытии схемы после ее сохранения ориентация форматки в норме, а вот эти же действия при сохранении топологии и повторном открытии в pcbnew имеют несколько различные последствия.
Если разводку платы сохранить в brd и потом вновь открыть, то форматка откроется так, как надо, а вот если сохранять разводку в kicad_pcb, то при повторном открытии вертикальная форматка А4 развалится на части: большая часть примет расположение горизонтальной форматки, а левая сторона вместе с полями останется стоять вертикально. Таким образом, при сохранении разводки в kicad_pcb форматка А4 искажается: левая сторона с полями остается неизменной, правая сокращается по высоте, а верхяя и нихняя сторона форматки напротив удлиняются, что и создает эффект «развалившейся форматки упавшей на бок».

Теперь несколько мыслей вслух.
1. Почему бы в pcbnew > Настройка правил > Общие правила проектирования не заполнить по умолчанию все 12 значений «особые переходные отверстия» и «особые дорожки»? Например, дорожки — 8, 10, 12, 16, 24, 36, 48, 60.., мил и соответствующие им переходные отверстия? Кому от этого будет плохо? Ведь эти размеры должны соответствовать определенным требованиям, да и набивать эти цифры гораздо дольше, чем удалить при надобности. Особенно это будет ценно для новичков, осваивающих не только сам кикад, но и сами навыки разводки. На мой взгляд это сделать не сложно, а польза большая.

2. Если пользователь pcbnew захочет распечатать избранные слои топологии и выберет опцию «по странице на слой», то получит несколько безымянных листов, если была выбрана печать без рамки, или столько же листов с поименованных за счет штампа в рамке, но каждый из листов будет иметь большой штамп первого листа. Так вот, на мой взгляд, не лучше ли будет сделать как в схематике: первый лист с большим штампом, а последующие с малым? Если это покажется спорным, можно будет сделать чекбокс для выбора старого варианта.

3. Обычно ближе к весне Жан Пьер выкатывает новую стабильную сборку и в этой связи начинается некоторое оживление и в КикадоГОСТоСтроении, с неизменным всплыванием темы «перечень-спецификация». Вот и в этот раз эта тема уже упоминалась. Так вот, хочу пожелать успехов нашим знатокам в окончательной победе над этим затянувшимся долгостроем. Я не прошу делать прогнозы и давать обещания, я просто хочу пожелать удачи!

если заглянуть во внутрь нового формата (kicad_pcb), то можно увидеть, что сохраняется только формат листа, а его ориентация нет. Похоже, недоработка...


Тоже задумывался об этом. По свободе займусь.

Так выходит, что и другие форматки при сохранении в kicad_pcb могут развалиться? Действительно, недоработка...

Как сугубый пользователь могу только пожелать удачи: Удачи!

А кто будет решать, какой из слоев будет на первом листе?

Предлагаю такой выход. Сейчас в PCBnew есть два варианта печати:
1. "По странице на слой" - указанные слои печатаются на отдельных листах с большим штампом.
2. "Одна страница" - указанные слои сводятся и печатаются на одном листе с большим штампом.
Добавляем еще один вариант:
3. "Комбинированный" (над названием нужно поработать ) - на первом листе с большим штампом печатаются все указанные слои сведенные вместе (общий вид), а на последующих, с малым штампом, каждый слой в отдельности.

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

Можно и так, но все слои сведенные вместе, если их много, в результате дают кашу. Нужно крепко подумать стоит ли именно так делать.
Хорошо бы услышать коллективное мнение, но наступили праздники со всеми вытекающими...

Выпуск КД на печатный узел часто регламентируется ОСТами.
У нас, например, как топологическая КД в архиве хранятся фотошаблоны слоев на пленке (программно добавляется основная надпись).
Для получения других чертежей обычно используется Компас (свободный аналог - LibreCAD).
Графические данные из KiCAD (например, для сборочного и чертежа отверстий) можно передать в них через DXF.
Есть возможность передать данные для ПЭ и раздела прочие изделия СП (на основе BOM-файла через конвертер ECAD-текстовая_КД
или программно формируя макросы документов на python, которые Компас кушает и которые можно править).

Делать ли модуль (или набор модулей) для выпуска КД в KiCAD - вопрос открытый. Видимо, надо делать.
LibreCAD - пока Beta. Недавно к нему подключен фонт opengost.ttf Н.Волченкова (аналог асконовского gost_type_a.ttf).
Такой шрифт в Kicad тоже не был бы лишним (все ecad начинали с векторных шрифтов).

https://bitbucket.org/fat_angel/opengostfont/downloads/

После почти 9 месяцев разработки вышла первая публичная версия шрифтового семейства OpenGostFont. Данные шрифты являются открытой реализацией шрифтов по ГОСТ 2.304–81 «Шрифты чертежные». Основными отличиями данной гарнитуры от существующих реализаций этих шрифтов, помимо свободной лицензии SIL OFL 1.1, является наличие кернинга для латиницы и кириллицы, а также более строгое следование дизайну глифов, приведенному в стандарте.

На данный момент проработаны прямые начертания шрифтов типа А и Б. Шрифты включают в себя базовую латиницу, греческий алфавит (без политонических символов), кириллицу (включая символы для украинского и белорусского языков) и различные символы. Кроме того, в разделе private use area добавлены символы для обозначений сварки по ГОСТ 2.312–72, допусков и посадок ГОСТ 2.308–79 и условные обозначения прокатных профилей, которые часто используются в технической документации и чертежах.

Загрузить шрифт в формате OpenType или TrueType, а также исходный текст в формате FontForge можно на домашней странице проекта, размещенного на Bitbucket.

Собрал, наконец, сам под Kubuntu (12.04) 86_x64 (по этой инструкции) .
Выявилась проблема с надписями (см. рис.) . Возможно из-за высокого разрешения экрана.

viknn
У нас на работе в архив принимают документацию в электронном виде. На плату - в виде архива с GERBER файлами. Сборочные чертежи делают в Нанокаде на основе преобразования через DXF. Напрямую из Pcbnew сборочный чертёж не получить.

О, кстати, я теперь научился собирать и доки с либами. Инструкцию ещё не обновлял, поэтому пока выкладываю обновлённый скрипт build-kicad-deb.sh сюда.
(перед запуском скрипта в дополнение к
bzr branch lp:kicad
сделать
bzr branch lp:~kicad-developers/kicad/doc
bzr branch lp:~kicad-lib-committers/kicad/library
)

Как решается вопрос с подписью? Применяете ли PDM-систему?

Хочу внести некоторые пояснения к тому, что я писал о выводе слоев на печать поскольку мое предложение несколько окультурить эту функцию плавно переросло в желание формумцев сделать вывод на печать некоего сборочного документа ПП оформеленного по ГОСТ.
Так вот, желая в глубине сердца вместе со всеми иметь именно такой солидный документ, я отдаю себе отчет в том, что это дело непростое и вряд ли будет скоро, а то и вообще реализовано. Поэтому, мое предложение было гораздо скромнее — при выводе нескольких слоев подряд делать большой штамп только на первом листе, остальные же листы должны быть с малым штампом. И все.
Для решения этой не самой сложной задачи в Кикаде, на мой взгляд, уже все есть, поэтому все может получиться, причем быстро. Если же замахиваться на солидную ГОСТ-сборку, то, как показала практика, этого можно ждать вечность. Этим я не хочу охладить пыл возможных новых энтузиастов, но просто смотрю реально на вещи.
Если суммировать и конкретизировать, то мое предложение звучит так: при выводе на печать последовательно нескольких слоев ПП, большой штамп делать только на первом листе, а на остальных листах делать малый штамп. Первым листом по умолчанию можно сделать верхний слой посадочных мест с обозначениями и габаритные размеры (это псевдо-общий вид), а последующие листы — слои отмеченные к выводу на печать. Данную фичу можно оформить отдельно как дополнение к «по странице на слой» и «одна страница» в виде некоего третьего выбора, но лучше всего просто доработать «по странице на слой» т. к. новый вариант полностью перекрывает старый. Если кому-то нужно будет распечатать каждый слой с большим штампом (странное желание), то это можно будет сделать воспользовавшись выбором «одна страница» и при этом выбрать к печати только один слой.
Итак, в данном случае я за синицу в руках, вместо бесконечного ожидания журавля в небе.

Все сторонние наблюдатели, глядя на мою работу в Кикад, не сговариваясь отмечают корявость шрифтов. Так что возможность решить эту проблему — добрая весть.
Хочется надеяться, что эти шрифты совсем скоро украсят если не интернациональную сборку, то уж ГОСТ-сборку точно. Было бы здорово обнаружить эти шрифты уже в стабильной сборке, рождающейся в эти дни.

Viknn, рассуждая о выводе документации из Кикад Вы пишете:

Из Ваших слов следует, что Компас позволяет сделать цивилизованный вывод текстовой документации из Кикад, а LibreCAD — свободный аналог Компаса. Если я правильно Вас понял, то такая работа с документацией налажена у Вас на фирме.
Вы автор не только русифицированной документации к Кикаду, но и многих пособий для работы с ним. Так может быть уже настало время родить пособие по выводу текстовой документации при помощи LibreCAD и неких программных примочек, о которых Вы пишете? Если Вы все это сделаете, то огромная благодарность в сердцах простых пользователей, вроде меня, Вам гарантирована.

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

Так скоро дела не делаются. Надо же код программы изменять. Потом мне например неизвестно как поддерживаются
в openfont языки типа китайского и японского.


Компас - отечественная программа, которая позволяет сделать цивилизованный (по ГОСТ) вывод КД.
Ей в основном пользуются для этого. Но красивой сквозной цепочки ECAD-КОМПАС пока не построено (и как ECAD, KiCAD
один из). Над этим думаем. Компаса пока нет под Linux (кроме Wine), хотя 3D-ядро уже перенесено.


LibreCAD - пока Beta. Насколько он цивилизован по ГОСТ предстоит оценить конструктору.
Надо найти время, чтобы поправить ru-доки eeschema/cvpcb/pcbnew-2013.
Можно попробовать будет сделать руководство по возможным связям kicad: pcad-kicad-pcad, altium_designer-kicad,
kicad-topor-kicad, python-kicad-python, kompas(lc)-kicad-kompas(lc), kicad-freecad.

Я грешным делом думал, что ввести новый фонт просто, как в Винде, подсунул в папочку и все. Только в нашем случае это нужно сделать при сборке. Простите мне мою дремучесть.
К тому же, если вводить новый фонт только в ГОСТ-сборке, то не нужно ждать согласия Жан Пьера, да и поддержка китайского с японским нам ни к чему.
Ладно, понял, что с новым фонтом для нышешней стабильной версии - облом.

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

Всем привет, не знаю было тут это или нет, но вот обнаружил недавно облако, для храненения поиска и распространения библиотек УГО и посадочных мест для kicad - kicadcloud.com , все исходники лежат на github поэтому если захотите можно поднять cвой собственный сервер.

Я такого не писал. Я сообщил, что LibreCAD стремится к тому, что будет поддерживать
формат DXF и opengostfont.ttf аналогично КОМПАС. Для равенства требуется немало работы
(в Аскон трудятся 7 сотен срециалистов). Я стараюсь следить за LibreCAD, но не могу выложить вам законченное решение.
Сообщение дано для форумчан типа Valber, которые тоже пытаются искать и увязывать opensource-программы.
А для нашей фирмы ПО АСКОН - базовое ПО, несмотря на платность и его недостатки (так сложилось).
Недостатки пытаемся совместно преодолеть.

На сколько смог, изучил текущую ветку форума.

Если я правильно понял, Андрей Федорушков и, видимо, другие делают сборку lp:kicad с дополнительной опцией -DKICAD_GOST=ON и выкладывают ее на ftp://kicad.r4b.ru/pub/kicad

Я столкнулся со следующей ситуацией.
Когда еще разработка KiCad велась в svn, у меня был доступ на запись в хранилище (мне предоставил доступ Игорь Плятов, который являлся администратором проекта KiCad, если не ошибаюсь до 2010г). Примерно с 2008г. у меня не было времени заниматься KiCad как и pcad2kicad, но был план прекратить дальнейшую разработку отдельной утилиты pcad2kicad в Delphi, а переписать ее с Delphi на c++ и встроить в KiCad. После чего исправить основные баги в pcad2kicad (основной баг был переполнение стека), ну и дальше поддерживать.
В июне 2012г. у меня появилась возможность заняться разработкой pcad2kicad снова. Я обнаружил, что разработка KiCad уже ведется не в svn, а в bzr, и в bzr у меня нет прав на запись. Я сделал запрос на восстановление моего доступа на запись. Жду уже с июня 2012, доступ так и не вернули. Проделал достаточно большой объем работы за это время по pcad2kicad, но по факту разочаровался, что вообще взялся за этот проект, по скольку ветка lp:~pcad2kicad-committers/kicad/pcad2kicad (ранее lp:~al-lunev/kicad/pcad2kicad) фактически живет отдельной жизнью отдельным проектом.

Получая рассылку от [Kicad-developers] со стороны разработчиков-администраторов KiCad часто вижу грубое недоброжелательное отношение к энтузиастам, решившим прислать какой-нибудь патч. С моей точки зрения, у любого такого энтузиаста сразу отпадет желание что-либо делать еще.

Итог. Лично со своей стороны видел выход - оставлять все как есть и в самом деле воспринимать lp:~pcad2kicad-committers/kicad/pcad2kicad как отдельный проект.

Общаясь с Юрием Викуловым (а он мне предложил посмотреть в эту ветку форума), я увидел, что оказывается, примерно с 2006 года Андрей Федорушков ведет параллельную ветку с ГОСТ версией, которая по умолчанию не собирается в lp:kicad, и со стороны администраторов проекта KiCad наблюдается безразличие к нашей российской действительности в плане поддержки ГОСТ.

Если я правильно все понял насчет ГОСТ ветки, то соответственно вопрос:

Как вы смотрите, если создадим ветку например lp:~russian-gost-committers/kicad/russian-gost и дадим в нее доступ на запись заинтересованным разработчикам (например, мне (Луневу Александру), Барановскому Константину и др.).
То есть образуем группу разработчиков, которые будут коммититься в lp:~russian-gost-committers/kicad/russian-gost, а Андрей Федорушков и Юрий Викулов, имеющие доступ на запись в lp:kicad, если согласятся, могли бы периодически выполнять merge в lp:kicad ?

При такой схеме, с одной стороны, существовал бы в некоторой степени независимый проект с поддержкой ГОСТ. С другой стороны, была бы возможность косвенно внедрять изменения в lp:kicad разработчикам, не имеющим доступ на запись в lp:kicad.

Да нет, у меня тоже нет доступа на запись в lp:kicad (был при Плятове, на svn).
Получается, что вносить GOST-правки можно только через Андрея. Сейчас, видимо,
надо сделать объединенный patch для выходящей стабильной версии.
Ну а дальше - возможно действительно вести параллельную ветку, периодически
синхронизируемую с основной веткой разработки. Надо послушать, что скажет Андрей.

Жаль. А я сделал такой вывод, когда увидел Вас в группе kicad-testing-committers.

jean-pierre charras час назад добавил в lp:kicad мои последние исправления, сделанные в pcad2kicad Pcbnew plugin.
Опять же выборочно. Конвертер pcad2kicadsch опять остался не у дел.

Поместил свежую версию конвертера схем pcad2kicad.exe на ftp://kicad.r4b.ru/pub/kicad/pcad2kicad/win32/
Там же (папка kicad2pcad) обратный конвертер схем в формат PCAD PDIF 8 (написан на Lazarus, от smoker771@yandex.ru)