Перейти к содержанию

Lion007

Клуб разработчиков
  • Публикаций

    609
  • Зарегистрирован

  • Посещение

  • Победитель дней

    75

Lion007 стал победителем дня 18 апреля

Lion007 имел наиболее популярный контент!

Репутация

378 Очень хороший

1 Подписчик

Информация о Lion007

  • Звание
    Разработчик nanoCAD

Информация

  • Пол
    Мужчина

Посетители профиля

Блок последних пользователей отключён и не показывается другим пользователям.

  1. пока никак не обстоят - стоит в планах. еше раз : внутренее растровое хранилище просто не поддерживает альфа-канал. вне зависимости от формата - не суть важно, это PNG, TIFF, GIF или что угодно - альфа-канал просто не читается. поэтому никакие галочки не помогут - немонохромный растр на данный момент непрозрачный. но сделаем. когда - вопрос отдельный, но сделаем.
  2. насколько показывают эксперименты - нет. и дело не в антикварном нанокаде 5.1 теоретически - ноль проблем. практически... я запросто могу представить, зачем это может понадобиться. но есть нюанс... есть пресловутый инспектор (который свойства). он показывает свойства выбранных объектов. если их несколько - то можно попробовать показать их куммулятивные свойства. вопрос только в том, как их сосчитать? объекты бывают сугубо разные, а свойство - одно на всех. вот загрузил я здоровенный чертеж. нажал "выбрать все". а там и линии, и кружочки, и размеры и черт лысый. и что я должен показать вместо длины? вот для текста, например - что? кому-то понадобится длина бэйзлайна - это допустим, выглядит логично. а как только это делается многострочный текст - это уже становится логично гораздо меньше. а то еще и кому-то захочется увидеть длину контура буквы (а если это тру-тайп - то еще и площадь)... собственно, вопрос совершенно законный - и отчасти даже логичный. но... куммулятивные свойства - штука очень сильно неоднозначная. и, к слову сказать, небыстрая. если речь идет о глобальном механизме, который аж прямо встроен - для него должны быть сформулированы понятные и адекватные правила. мы вполне можем высосать их из пальца - но едва ли это правильно. вот для примера - только общая длина линий? а чего это! полилинии тоже надо учесть. а у полилиний есть дуговые сегменты - значит считаем и дуги... а раз дуги - то и окружности тоже не стоит обходить стороной. а там в очереди стоят эллипсы со сплайнами, а также спирали и прочие кривые - а чем они хуже? а еще у меня трехмерка есть - там у каждого тела есть ребра... считаем? или как? и если считаем - то у цилинда считаем что - две длины окружности по торцам, или еще и боковинку? а кто-то захочет площадь... а ее как считать - только для замкнутых кривых, или для трех отдельных линий, которые треугольник образуют тоже? и для плоского замкнутого сплайна посчитать площадь не фокус, хоть и не быстро - а если он пространственный? а дальше объемы подойдут... в общем, это я все к чему : хорошего универсального решения - тут не видится. если я не прав - аппелирйуте, обсудим. а для любой частной задачки... сосчитать длину кусочком скрипта - не фокус. единственный вопрос - а как сосчитать длину RAY\XLINE, которые бесконечны по определению
  3. известная хохма... на самом деле - ридеры не зависают, а просто долго думают. секунд 30-40 - запросто. в технологические подробности вдаваться сходу не стану, но 11 - работает так. спасибо майкрософту за нашу нескучную жизнь - их полигональный клип работает хреново почти всегда. на экран нормально, а вот на печать - как повезет. в 20-ке сделали уже по-другому, там и файлы получились потоньше, и открываются быстрее. да и печать... среднепотолочно - оно лучше.
  4. для 11 это смысла не имеет - там не было такого вообще, в 20-ке появилось
  5. технически - можно попробовать поиграться с настройками... секция регистри HKEY_CURRENT_USER\Software\Nanosoft\nanoCAD <какой-он-там-есть>\<нужная версия>\Profiles\<<Default>>\Graphics там есть пара параметров - UseBitmapFonts и MaxBitmapFontSize первый - это просто включалка-выключалка хитрого рисования мелких TTF. имеет вид (по дефолту) 05 00 00 00 01 00 00 00. если вместо единички поставить нолик - то выключится а второй - это пороговый размер (в пикселях на экране), при котором это хитрое рисование включается. имеет вид (по дефолту) 05 00 00 00 40 00 00 00 - т.е. 64 (40 шестнадцатиричное - это как раз 64 и есть). можно поставить поменьше.
  6. я в курсе. именно поэтому файлик, который я приложил - в UNIX-формате, там перевод строки - это ОДИН символ
  7. должно... копипаст в комстроку, насколько помню, был изначально
  8. второй раз-то зачем запускать? ну не скопировался последний пробел (а он нужен!) - так можно руками ввод нажать в любом случае, если полилайн отработал - значит контур уже есть. топаем два раз колесом мышки или просто зовем ZOOM EXTENTS
  9. ничего выбирать не нужно - просто вставляем весь текст в комстроку. что касается X и Y - это вам виднее, в какой системе координат точки заданы. если их надо местами поменять - то можно просто развернуть UCS - на 90 градусов вокруг Z а потом на 180 вокруг X
  10. открыть файлик (например во вьювере total-коммандера или в notepad), контрол-A, контрол-C, а потом вставить в командную строку наны.... Координаты-pline.txt
  11. ну так я про это и говорю - на каждом шаге оно уменьшается на те самые 5%... а пример я просил, опасаясь того, что оно с первого раза в бесконечность улетит меня, честно говоря, больше ситуация 2 напрягает... видимо, базовую точку все-таки придется воткнуть - и хрен с ними с эффектами...
  12. пример в студию! потому что по моим наблюдениям, да и исходя из логики кода, работает оно совсем не так - в экран вписывается видимая часть икслайна. более того, если его в данный момент совсем не видно (ну уехал за экран, бывает) - то он как бы и не участвует в процессе. - рисуем кружочек - в сторонке рисуем xline - давим alt-0 наблюдаем постепенное уменьшение картинки (при зум-олл, насколько помню 5% свободного места по краям остается) - теперь сдвигаем картинку так, чтобы наш xline уехал за экран. - опять давим alt-0 наблюдаем зум к кружочку все это, безусловно, не особо радует, но трагедией, имхо не является. включить в рассмотрение базовые точки - идея, в общем-то , вполне здравая, формально правильная и даже легко реализуемая - но тут есть свои побочные эффекты... это я не к тому, что сейчас все сделано на "вау!" - просто вопрос вовсе не такой очевидный, как может показаться на первый взгляд. но и до него руки дойдут, не знаю как кого - а меня он уже не первый год раздражает
  13. XLINE и RAY - это проблема старая и известная. если не вдаваться глубоко в детали, то заключается она примерно в следующем : что считать экстентсами бесконечного объекта? вариантов, по большому счету, два, и оба так себе варианты, кривоватые - либо видимую часть, либо точки определения того самого xline. побочные эффекты имеют оба, какой вариант лучше - вопрос спорный. по большому счету, кмк, важность проблемы на самом деле минимальная, приближенная к никакой. переделывать, вероятно, будем - но по остаточному принципу, вот честное слово, есть задачи поважнее!
  14. АС1032 - это формат АС2018. как нетрудно догадаться, появился он в 2018 году. антикварный 5.1 его не читает (и не может) в принципе. чтобы работало - надо пересохранить в один из поддерживаемых 5.1 форматов - скорее всего подойдет 2013, но это лучше глянуть в самом 5.1 (в диалоге Save As развернуть список форматов и глянуть, что он поддерживает).
  15. UCS (она же ПСК), и выбрать опцию "world" ("мир") - или просто нажать на ввод. поставится исходная мировая система координат.
×
×
  • Создать...