EdwardSt

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

Попробуйте так StripMtext v5-0c1.lsp Кстати, этот код вроде что-то делает в 21.0, а в 20.1 ругается еще и на функцию (ssget...) Сложная она...

См. приложение. В простых случаях вроде работает. Может сойдет? PS. Нужно более детально пройтись по всему коду. Проблема в функциях (vl-bb-ref ...) и (vl-bb-set ...) Они имеют смысл в автокаде, но не в нанокаде. В начале файла заменил, а дальше было лениво. StripMtext v5-0c1.lsp

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

Спасибо, починили.

Озвученная проблема слово в слово повторяет начало ветки Что-то произошло на сайте?

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

Позволяет. Входит в редактор мтекта одного из элементов, а после подтверждения меняет такой-же атрибут и у остальных объектов.

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

Если такой возможности нет (а ее, похоже, нет), то она должна быть. Это явный косяк.

Ты будешь еще более удивлен, что в рамках платформы Вот только особенно поисследовать эту фичу у меня возможности нет. Поэтому дождемся внятных советов автору ветки от уверенных пользователей сервиса добавлено через 3 минут скорее всего имеется ввиду местная система координат не в нотациях нанокада, а географичекие понятия региона. У нас в Питере карты поставляют с координатами 0,0 гдето на западе области (балтийская система высот). В других регионах - свои МСК

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

нет

Это самый большой косяк, непонятно как купируемый. Ранее в обсуждениях было приведено объяснение, что это происходит вследствие того, что картинка при использовании стиля визуализации, отличного от 2D, растеризуется без образования слоев. Непонятно только, почему при этом не используется А вот со штриховкой и фоном мтекста не понял... Вроде все ожидаемым образом, кроме снижения векторной графики при растеризации

Вроде бы можно печатать. Для примера взял файл из приложенных выше, и внес некоторые коррективы, а именно: -установил прозрачность для растров - 50% -настроил 2 листа с печатью на "встроенный принтер" и "принтер в формате" Отмечу несколько моментов: 1. Печать с заданными настройками ИЗ МОДЕЛИ для обоих принтеров дает практически одинаковые результаты , соответствующие ожидаемым: Веса линий оказались слишком маленькими, поэтому штрих-пунктир практически не виден, но он есть 2. Печать из листа на принтер "Печать в формате pdf" просто тупо крашит