Для устранения ошибки масштабирования по размеру листа при выводе на печать в pcbnew необходимо сделать исправления в файле printout_controler.cpp. Исправленный файл прилагается

А нельзя ли это оформлять патчиками? Мне не трудно самому сделать diff, но это времени займет больше.
И кого записать автором коммита? Или хотя бы кому написать "txh ..." в комментарии к коммиту?

ЗЫ: Проверил. При нормальном - старается размещать по центру листа.
При зеркальном - не помогло, выходит за границу. Проверял при масштабе 1.4 и 2.
Пока коммитить не буду.


Сообщение отредактировал faa - Apr 29 2011, 09:51

В сборке 2011-03-29 GOST-stable заметил: при добавлении 3D-представления под виндовсом путь к нему прописывается с обратными косыми. А при сохранении эта одна обратная косая заменяется на две (и в библиотеку и в плату). При загрузке эти две косые опять превращаются в одну. Раньше раздвоения не было. И вообще - корректно ли использование в библиотеке кросс-платформенного пакета обратных косых в путях?

В *nixaх обратная косая в тексте - это символ экранирования для следующего за ней символа. \r\n = ВК ПС, \\ = \
\\ заменяются под виндой на \, а под линухом и макосью на /.
Это позволило (наряду с указанием кодировки в файлах) читать и писать файлы на любых системах.
Теперь можно записать файл схемы, платы, библиотеки в винде и без всяких лишних телодвижений прочитать их в линухе.
Раньше надо было перекодировать из cp1251 в utf8 и обратно, а еще и пути править - менять обратные косые на прямые и обратно (подарок вот такой от БГ).
ЕМНИП, в СР-М были прямые косые, в ДОС вдруг стали обратные.

Сообщение отредактировал faa - Apr 29 2011, 10:52

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


И вот еще большая неприятность обнаружилась. При групповом обновлении посадочных мест (Посадочное место-> Правка->Change module(s)) компонент(ы) смещаются со своих мест в узлы текущей выбранной сетки. А еще хотелось бы чтобы при таком обновлении уже сдвинутые поля оставались на своих местах, а не прыгали в начальное положение.

зачем ? не проще все писать в UTF8 ?в Win нормально воспринимаются пути с прямыми слешами ?

С этого места поподробнее.
Какие поля? Или это модули (посадочные места)?
Компоненты (модули) были залочены?
Сетка крупнее старой?



А разве винда понимает utf8 из файла?
Сколько в ХР не открывал блокнотом файлов в утф8 - такая красота на экране получалась.
Для переноса линух-винда приходилось iconv и dos2unix/unix2dos привлекать.

Да, речь о посадочных местах (и кто придумал обзывать их модулями?). Подправил, скажем, какой-то модуль в библиотеке. Хочу обновить его в плате. Выбираю Посадочное место-> Правка->Change module(s), компонент обновляется но съезжает в текущую сетку. Дорожки от него, естественно, отрываются. Компонент не залочен (заемучаешься лочить все компоненты перед обновлением, да и как-то не приходит в голову, что обновление должно включать в себя сдвиг). Сетка может быть и крупнее и мельче и вообще не кратные - скажем, расстановка в 0.635 а текущая стоит 0.5 или наоборот.

Поля - имеются ввиду RefDes, Value и прочие у посадочных мест. Расставил я их как мне надо для шелкографии или сборочника (как же не хватает еще пары из верхнего/нижнего неэлектрических слоев для сборочника!), потом потребовалось обновить компонент - и расставляй заново. В PCAD в этом смысле было удобно - пока не двигал поле отдельно от компонента - его положение обновляется если изменилось в библиотеке. Но если в плате что-то вручную изменил в поле - подвинул, размер шрифта поменял - все, оно больше не будет затронуто при обновлениях компонента.

wordpad и другие нормальные редакторы понимают.

Исправил центровку при выводе на печать в pcbnew, теперь работает во всех режимах включая зеркалку. Файл printout_controler.cpp используется также и при печати в gerberview, но там вывод производится несколько иначе, поэтому я сделал изменения только для режима печати в pcbnew, а в gerberview оставил как есть. Проверял под windows. Патч прилагается, использовать так: перейти в корневой каталог сборки и запустить patch -p1 -i путь к патчу/pcbnew.patch. На всякий случай прилагаю исправленный файл.

Не работает
Вот с такими установками:

Вот прямо:

Вот зеркально:

Есть такая неприятность.
Пофиксил в bzr2989.
А вот с полями править побольше надо - посмотрю на досуге.

Прочитав эти слова, а также в предыдущих сообщениях об исправлении центровки при выводе на печать в pcbnew, впал в задумчивость.
Дело в том, что осваивать KiCAD я начал не со стабильной версии и более года пользовался самыми свежими нестаб. сборками, желая быть на гребне нового. Но однажды, именно в тот момент, когда я расслабился и не сделал своевременно бэкап, KiCAD рухнул испортив часть проекта и даже (до сих пор не пойму каким образом) часть библиотеки в схематике.
После этого я твердо решил, что хватит с меня экспериментов и откатился на стабильную версию, которой пользовался до выхода последнего релиза. Но, как видим, он имеет весьма заметные баги, которые постепенно исчезают трудами наших добрых программистов.
И вот теперь передо мной дилемма: пользоваться новым релизом с багами или вновь начать пользоваться нестабильными сборками ради того, чтобы работать без этих багов, но рискуя опять налететь на что-то более неприятное. Этой дилеммы удалось бы избежать, если бы последний релиз после устранения багов был бы перевыпущен.
В этой связи вопрос к faa: планируется ли перевыпустить последний релиз после того, как замеченные баги будут исправлены?

------

Кстати, зашел сейчас на фтп Жан Пьера http://iut-tice.ujf-grenoble.fr/cao/ и вижу там 29/04/2011 kicad-2011-04-29-BZR2986-stable-UBUNTU_10.10_full_with_components_doc.tgz и KiCad-2011-04-29-BZR2986-WinXP_full_with_components_doc_install.exe. Это что, еще более новый релиз?
Так вот, все удачно и складывается: новая ГОСТ-сборка самого последнего релиза выйдет с пофиксенными багами и "усе будет у полном порядке". :-)

Сообщение отредактировал Aldan - May 3 2011, 17:57

Планируется в ближайшее время.

Это добрые вести. Только, если я правильно понял, теперь планируется не перевыпуск мартовского релиза, а выпуск самого последнего релиза (если это релиз?) от 29/04/2011?
Впрочем, после выпуска сборки все будет ясно. Ждем-с

Сообщение отредактировал Aldan - May 5 2011, 09:43