Поддерживаю BlackPrapora. Наличие открытого формата упростит написание сопутствующего ПО (конверторы и прочее) и, как следствие, популяризует исходный продукт.

Чем, интересно, не нравится формат PCAD ASCII, который понимает ТороР? Зачем надо изобретать велосипед?

Отвечаю для непонятливых. Формат P-CAD ASCII заточен под Пикад (логично, да? )
После импорта его в Топор проект нуждается в доработке. Ручками. Далее, в процессе трассировки текущие версии сохраняются уже в родном Топоровском формате. Экспорт их в P-CAD ASCII - лишний гемор, а также потеря части данных, специфических для Топора. Вот такие пирожки с котятами

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

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

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

Уверен, что программисты меня поймут. Работа с родным форматом САПРа всегда удобнее и предпочтительнее. Форматы можно сравнить с языками - набор слов везде примерно одинаков, но трудности перевода существуют.

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

Думаю язык (родной формат) будет понятен только людям с учеными степенями...
И кому от такого языка станет легче?!
Или все в совершенстве триангуляцию знают?

PS:
Подобные размышления ни к чему не приведут, ИМХО. Если б можно было то открыли бы еще лет "дцать" назад.

Сомневаешься - не говори. У меня нет никаких степеней, но это никак не мешает мне знать форматы Пикада и Оркада. Скоро до Ментора доберусь
При чем тут триангуляция? Я говорю про формат, в котором Топор хранит ТОПОЛОГИЮ платы. А не про методы, которыми он ее создает. Разницу улавливаешь?

Не вижу смысла в этих дебатах. Даже если предположить возможность наличия транслятора Ментор-Топор то какой в нем смысл? Топологию он передаст, расположение элементов, контур платы, зоны запрета, фиксацию... и все? А как насчет желаемой топологии трассировки? Последовательность трассировки типа Daisy в зависимости от атрибутов пинов(source-load-terminator)? Эти атрибуты Топор понимает или нет? А как быть с классами, группами, дифф. парами, фанаутами для разных типов корпусов и т.д.? Если Топор все это не принимает во внимание в процессе трассировки - то какой смысл в наличии подобных трансляторов? Будут ли люди использующие проги от Ментора пользоваться Топором в качестве автороутера? Мне кажется нет.

Сфера применения открытого формата не ограничивается транслятором Ментор-Топор.
Кстати, что-то я не слышал восторженных отзывов о Менторовском автороутере
Ответы на большинство твоих вопросов, Uree, могут дать только Фристайлеры. Технически я здесь особых проблем не вижу

Сообщение отредактировал Жека - Apr 19 2006, 12:39

О какой работе одет речь? Я не улавливаю. Пока что упоминались только конверторы форматов. Получается мартышкин труд какой-то: откройте нам еще один формат, мы (может быть) бросимся писать для него конверторы, иначе - вы сдерживаете развитие. А если вы уже общаетесь в уже известном и хорошо описанном формате - это нам не подходит, потому что... (тут я затрудняюсь даже сказать почему, я так и не понял). Странная какая-то логика.

Не нравится Вам PCAD ASCII - напишите для него конвертер и работайте дальше в любом удобном Вам формате, кто ж мешает? И с чего Вы решили, что внутренний формат ТопоР-а облегчит Вам жизнь хоть в на йоту?


Тем более, зачем тогда еще один язык? Только для того, чтобы потом переводить на него/с него всю мировую литературу? Не понимаю.

=AK=, Вам знакомо такое явление - САПР в котором Вы работаете, что-то делает не совсем так (или совсем не так), как Вам хочется? Решать вопрос через техсаппорт, даже являясь зарегистрированным пользователем, долго и не всегда продуктивно. Часто проще на месте написать нужную примочку.
Вот мне и нужен формат для создания примочек к Топору. Это называется, если Вы не в курсе, открытая архитектура
Если Вас все всегда устраивает в САПРах, нам не о чем разговаривать. Имеющий уши да услышит

Знакомо, ессно. До боли.

Только то, что Вы предлагаете - это беспардонная партизанщина. Такие вещи принято решать другими способами. Например, плагинами, для чего пакет должен их поддерживать. Или хорошим встроенным скриптовым языком (предел мечтаний - что-то наподобие Автокада с его АвтоЛИСП-ом)

ЗЫ: Никогда не пробовали смотреть результат после ТопоР-а? Имхо, с таким обилием дуг простыми методами не справиться. Нужен доступ не к "мертвому" формату данных, какой бы он ни был, а к самим внутренним объектам, включая их методы. Поэтому плагины или скрипты предпочтительнее.

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

Доступ к внутренним объектам - это было бы просто супер Но это уже задача-максимум, создать API, COM-интерфейс и т. п. Это более запарно для разработчиков.

Там наверняка есть еще куча подводных камней. Например, связанных с "владением" тем или иным файлом. Если пакет "следит за своим добром", то все может хорошенько грохнуться во время правки. И еще проблемы связанные с "проверкой достоверности" данных. Если формат внутренний, то можно ограничиться простейшей проверкой, например, контрольной суммой. А если он открытый, и кто угодно мог в файл влезть и сикось-накось его отредактировать, значит, придется его долго и нудно парсить и проверять на ошибки. Вся реактивность пойдет коту под хвост, да и сам ТопоР раздуется неимоверно. Нет, это ложный путь.

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