Олег. 0 29 апреля, 2011 Опубликовано 29 апреля, 2011 · Жалоба Для устранения ошибки масштабирования по размеру листа при выводе на печать в pcbnew необходимо сделать исправления в файле printout_controler.cpp. Исправленный файл прилагается :rolleyes: printout_controler.zip Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
faa 4 29 апреля, 2011 Опубликовано 29 апреля, 2011 (изменено) · Жалоба Для устранения ошибки масштабирования по размеру листа при выводе на печать в pcbnew необходимо сделать исправления в файле printout_controler.cpp. Исправленный файл прилагается :rolleyes: А нельзя ли это оформлять патчиками? ;) Мне не трудно самому сделать diff, но это времени займет больше. И кого записать автором коммита? Или хотя бы кому написать "txh ..." в комментарии к коммиту? ЗЫ: Проверил. При нормальном - старается размещать по центру листа. При зеркальном - не помогло, выходит за границу. Проверял при масштабе 1.4 и 2. Пока коммитить не буду. Изменено 29 апреля, 2011 пользователем faa Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 132 29 апреля, 2011 Опубликовано 29 апреля, 2011 · Жалоба В сборке 2011-03-29 GOST-stable заметил: при добавлении 3D-представления под виндовсом путь к нему прописывается с обратными косыми. А при сохранении эта одна обратная косая заменяется на две (и в библиотеку и в плату). При загрузке эти две косые опять превращаются в одну. Раньше раздвоения не было. И вообще - корректно ли использование в библиотеке кросс-платформенного пакета обратных косых в путях? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
faa 4 29 апреля, 2011 Опубликовано 29 апреля, 2011 (изменено) · Жалоба В сборке 2011-03-29 GOST-stable заметил: при добавлении 3D-представления под виндовсом путь к нему прописывается с обратными косыми. А при сохранении эта одна обратная косая заменяется на две (и в библиотеку и в плату). При загрузке эти две косые опять превращаются в одну. Раньше раздвоения не было. И вообще - корректно ли использование в библиотеке кросс-платформенного пакета обратных косых в путях? В *nixaх обратная косая в тексте - это символ экранирования для следующего за ней символа. \r\n = ВК ПС, \\ = \ \\ заменяются под виндой на \, а под линухом и макосью на /. Это позволило (наряду с указанием кодировки в файлах) читать и писать файлы на любых системах. Теперь можно записать файл схемы, платы, библиотеки в винде и без всяких лишних телодвижений прочитать их в линухе. Раньше надо было перекодировать из cp1251 в utf8 и обратно, а еще и пути править - менять обратные косые на прямые и обратно (подарок вот такой от БГ). ЕМНИП, в СР-М были прямые косые, в ДОС вдруг стали обратные. ;) Изменено 29 апреля, 2011 пользователем faa Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 132 29 апреля, 2011 Опубликовано 29 апреля, 2011 · Жалоба Раньше надо было перекодировать из cp1251 в utf8 и обратно, а еще и пути правитьНо ведь и в предыдущих версиях кикада и в текущей винда прекрасно ест пути с прямыми косыми. Зачем было вводить эту дифференциацию? Создал файл под линухом, открыл в винде, исправил одну букву, а система контроля версий вынуждена переписывать все строки файла с путями. И вот еще большая неприятность обнаружилась. При групповом обновлении посадочных мест (Посадочное место-> Правка->Change module(s)) компонент(ы) смещаются со своих мест в узлы текущей выбранной сетки. А еще хотелось бы чтобы при таком обновлении уже сдвинутые поля оставались на своих местах, а не прыгали в начальное положение. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ukpyr 0 29 апреля, 2011 Опубликовано 29 апреля, 2011 · Жалоба Раньше надо было перекодировать из cp1251 в utf8 и обратно, а еще и пути правитьзачем ? не проще все писать в UTF8 ?Теперь можно записать файл схемы, платы, библиотеки в винде и без всяких лишних телодвижений прочитать их в линухе.в Win нормально воспринимаются пути с прямыми слешами ? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
faa 4 29 апреля, 2011 Опубликовано 29 апреля, 2011 · Жалоба И вот еще большая неприятность обнаружилась. При групповом обновлении посадочных мест (Посадочное место-> Правка->Change module(s)) компонент(ы) смещаются со своих мест в узлы текущей выбранной сетки. А еще хотелось бы чтобы при таком обновлении уже сдвинутые поля оставались на своих местах, а не прыгали в начальное положение. С этого места поподробнее. Какие поля? Или это модули (посадочные места)? Компоненты (модули) были залочены? Сетка крупнее старой? зачем ? не проще все писать в UTF8 ? А разве винда понимает utf8 из файла? Сколько в ХР не открывал блокнотом файлов в утф8 - такая красота на экране получалась. Для переноса линух-винда приходилось iconv и dos2unix/unix2dos привлекать. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 132 29 апреля, 2011 Опубликовано 29 апреля, 2011 · Жалоба С этого места поподробнее. Какие поля? Или это модули (посадочные места)? Компоненты (модули) были залочены? Сетка крупнее старой? Да, речь о посадочных местах (и кто придумал обзывать их модулями?). Подправил, скажем, какой-то модуль в библиотеке. Хочу обновить его в плате. Выбираю Посадочное место-> Правка->Change module(s), компонент обновляется но съезжает в текущую сетку. Дорожки от него, естественно, отрываются. Компонент не залочен (заемучаешься лочить все компоненты перед обновлением, да и как-то не приходит в голову, что обновление должно включать в себя сдвиг). Сетка может быть и крупнее и мельче и вообще не кратные - скажем, расстановка в 0.635 а текущая стоит 0.5 или наоборот. Поля - имеются ввиду RefDes, Value и прочие у посадочных мест. Расставил я их как мне надо для шелкографии или сборочника (как же не хватает еще пары из верхнего/нижнего неэлектрических слоев для сборочника!), потом потребовалось обновить компонент - и расставляй заново. В PCAD в этом смысле было удобно - пока не двигал поле отдельно от компонента - его положение обновляется если изменилось в библиотеке. Но если в плате что-то вручную изменил в поле - подвинул, размер шрифта поменял - все, оно больше не будет затронуто при обновлениях компонента. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ukpyr 0 29 апреля, 2011 Опубликовано 29 апреля, 2011 · Жалоба А разве винда понимает utf8 из файла? Сколько в ХР не открывал блокнотом файлов в утф8 - такая красота на экране получалась.wordpad и другие нормальные редакторы понимают. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Олег. 0 30 апреля, 2011 Опубликовано 30 апреля, 2011 · Жалоба Исправил центровку при выводе на печать в pcbnew, теперь работает во всех режимах включая зеркалку. Файл printout_controler.cpp используется также и при печати в gerberview, но там вывод производится несколько иначе, поэтому я сделал изменения только для режима печати в pcbnew, а в gerberview оставил как есть. Проверял под windows. Патч прилагается, использовать так: перейти в корневой каталог сборки и запустить patch -p1 -i путь к патчу/pcbnew.patch. На всякий случай прилагаю исправленный файл. pcbnew_patch.zip printout_controler.zip Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
faa 4 3 мая, 2011 Опубликовано 3 мая, 2011 · Жалоба Исправил центровку при выводе на печать в pcbnew, теперь работает во всех режимах включая зеркалку. Не работает :( Вот с такими установками: Вот прямо: Вот зеркально: Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
faa 4 3 мая, 2011 Опубликовано 3 мая, 2011 · Жалоба И вот еще большая неприятность обнаружилась. При групповом обновлении посадочных мест (Посадочное место-> Правка->Change module(s)) компонент(ы) смещаются со своих мест в узлы текущей выбранной сетки. А еще хотелось бы чтобы при таком обновлении уже сдвинутые поля оставались на своих местах, а не прыгали в начальное положение. Есть такая неприятность. :( Пофиксил в bzr2989. А вот с полями править побольше надо - посмотрю на досуге. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aldan 0 3 мая, 2011 Опубликовано 3 мая, 2011 (изменено) · Жалоба Есть такая неприятность. :( Пофиксил в 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. Это что, еще более новый релиз? Так вот, все удачно и складывается: новая ГОСТ-сборка самого последнего релиза выйдет с пофиксенными багами и "усе будет у полном порядке". :-) Изменено 3 мая, 2011 пользователем Aldan Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
faa 4 5 мая, 2011 Опубликовано 5 мая, 2011 · Жалоба В этой связи вопрос к faa: планируется ли перевыпустить последний релиз после того, как замеченные баги будут исправлены? Планируется в ближайшее время. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aldan 0 5 мая, 2011 Опубликовано 5 мая, 2011 (изменено) · Жалоба Планируется в ближайшее время. Это добрые вести. Только, если я правильно понял, теперь планируется не перевыпуск мартовского релиза, а выпуск самого последнего релиза (если это релиз?) от 29/04/2011? Впрочем, после выпуска сборки все будет ясно. Ждем-с :) Изменено 5 мая, 2011 пользователем Aldan Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться