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

Lion007

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

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

  • Посещение

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

    69

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

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

Репутация

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

1 Подписчик

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

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

Информация

  • Пол
    Мужчина

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

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

  1. в совсем старых - может и нет, но, по идее, сделано давно. тут, скорее, другой хитрый вопрос - а не имелась ли в виду не яркость (оно и раньше работало) а прозрачность? и вот тут начинается цирк с конями... не все принтеры поддерживают прозрачность вообще. причем узнать это снаружи - мягко говоря проблематично. то есть ты ему "вот тебе прозрачный квадратик!" - а он тихонько бурчит себе в картридж "хрен, тебе, а не прозрачный! радуйся, что вообще нарисую!"... но, допустим, XPS - поддерживает. тут выясняется, что код печати растров (наш) - ту самую прозрачность сам по себе тихонечко игнорирует... но это ладно, все равно он сейчас в переделке (потому что, например, тот же самый XPS фигово работает с большими растрами) - глядишь и прозрачность протащим. но на принтерах, которые ее не поддерживают - все равно радости будет мало. при этом, когда вывод идет на бумагу - все равно можно выкрутиться - сформировать уже готовую картинку (с учетом всей клюквы) - и отправить ее на печать именно как картинку. но при выводе в файловые форматы это далеко не всегда подходит. в том же PDF, например, народ хочет еще и тексты искать, а какие тексты, если оно все картинкой? собственно, в режимах, которые "не вайрфрэйм" - оно так и работает - печатается именно картинка, никаких векторов, и это можно использовать, когда возникают траблы с прозрачностью. такая вот хистория...
  2. воля ваша, коллеги, но что-то вы неправильно делате... или я неправильно что-то делаю... вставил растр. размножил его 5х5 штук - для наглядности. по строкам - фэйд с шагом 20. по столбцам - яркость с шагом 10. распечатал (XPS и PDF) получается примерно вот так : ну и до кучи... rasters.dwg rasters.pdf rasters.xps
  3. а растр какой? RGB, монохром или еще какой? а лучше всего - пример в студию!
  4. да пожалуйста, мне не жалко, для того и писалось! я рад, что хоть кто-то оценил... а чтобы было не так смешно - немного оффтопиковой философии поэты - обижаются, когда им говорят, что они складывают стихи. художники - обижаются, когда говорят, что они рисуют картины музыканты - ну, они как первые и вторые... я - смеюсь, когда говорят, что программисты составляют программы. на самом деле - все пишут... каждый свое. а если ты можешь написать что-то действительно свое - то сочинить пост на форуме - право, не фокус! а по вопросу.... в разработчики меня занесло по жизни. первую ошибку у отца в программе (согласно семейной легенде) я исправил примерно года в 3.5... беда в том, что я отлично помню этот момент, равно как свои 38.5 в этот момент - болел, однако... в общем, можно с полным правом считать это понтами - но я программер от бога. не то, чтобы это меня ставило выше прочих - нет, это просто талант... как музыкальный слух или способности к гимнастике. остальное - ручками... но это я уже выпендриваюсь... зы : про скучных программистов - это придумали не те люди, к которым лично я рекомендовал бы прислушиваться. программировать просто, интересно и весело!
  5. рассказываю физику процесса... невидимая карточка компутера умеет рисовать точки, линии и треугольнички. механизм растеризации (т.е выбор, какие пиксели на экранчике нарисовать, а какие нет) для каждого типа примитивов свой. если несколько упростить... ну, точка, понятно, просто рисует пиксель, в который попала (пиксель это все-таки квадратик). линия - те пиксели, центры которых лежат к ней ближе всего. а треугольничек - те пиксели, центры которых попали в этот треугольник. из этого следует несколько выводов : 1) точка рисуется всегда (ну, если попала в экран, ясное дело) 2) линия может пропускать пиксели, в которые (как в квадратики) попадают ее концы. звучит глупо, но это на самом деле правильно - иначе если мы нарисуем две линии с общей вершиной, пиксель эту общую вершину содержащий, нарисуется дважды, а это уже глубоко неправильно. 3) треугольник вообще выбирает пиксели как повезет, и это, как ни странно, тоже правильно - по той же причине (чтобы 2 треугольника с общим ребром не рисовали его дважды). далее, из пунктов 2 и 3 следует, что - линия длиной меньше пикселя имеет полное право не нарисоваться вообще - треугольничек размером меньше пикселя имеет полное право не нарисоваться вообще - узенький треугольник имеет право не рисоваться вообще, либо нарисоваться в виде цепочки разрозненных пикселей, не образующих непрерывную фигуру это была преамбула, а теперь будет амбула... буква TTF - это набор сплайновых контуров, внутренность которых надо закрасить. как это рисовалось? а очень просто - эта самая внутренность билась на треугольнички (точность, кстати, регулируется параметром TEXTQUALITY), и дальше эти самые труегольнички и отрисовывались. но, как мы уже выяснили, треугольнички могут нарисоваться как угодно - и тонкие элементы букв (состоящие, естественно, из маленьких-узеньких треугольничков) запросто превращались в отдельные точечки, букву никоим образом не образующие. тут надо заметить, что антиалиасинг эту проблему отчасти маскировал (поскольку там получался меньший эффективный размер пикселя) - но именно отчасти. с антиалиасингом тоже могло все развалиться... чтобы-таки получилась буква - по контуру всего этого безобразия рисовалась обводка линиями. но линии-то растеризуются иначе! из-за чего и получалось "жЫрно"... так что при такой механике были ровно те два варианта, которые я уже описывал - либо жирно, либо фрагменты букв пропадали (если без обводки). добавляем сюда необходимость масштабирования буквов в невменяемых пределах и получаем полную задницу... в результате пришлось знатно поизвращаться, чтобы всего этого избежать - а руки до этих извращений у меня дошли только сейчас. но поизвращался - сделал. такая вот хистория...
  6. не было в 10-ке нормально. было в разное время два варианта и оба не фонтан - либо с обводкой по контуру (тогда получается жирно) либо без (тогда тонкие элементы букв пропадали). пришлось извращаться - но получилось, в результате, вроде неплохо...
  7. в 11 - нету. а вот для следующей версии уже переделали, так что там все должно быть путем.
  8. тут есть нюанс... я, признаться, не поклонник динамического ввода - но я ретроград известный... так вот - все работает.... просто для этого надо вводить что-то не в динамический размер, а в командную строку. надо будет, конечно, об этом подумать - но с общем случае задачка как минимум нетривиальная - отличить ввод конкретного поля (дин. размера) от общекомандного кейворда. но подумаем... а так - все правильно, сокращения подсвечены в списке кейвордов заглавными буквами. ну, или на гиперссылочки в комстроке тыкать.
  9. друзья, а вам не кажется, что мы несколько отклонились от темы? ну, по крайней мере - от темы "с какого перепуга при попытке повернуть UCS вокруг X зовется эксплод, а вокруг Z- зум. надеюсь, я достаточно рассказал о технических деталях - что как происходит, почему оно происходит именно так и зачем это надо. возвращаясь к первоисточнику холивара... да без проблем - фигня война, накатать три отдельные команды - ну, (условно) типа UCS_ROTATE_X, ну и _Y _Z соответственно. на все про все - полчаса. тем более, что в кишках - это все равно упрется ровно в один и тот же код.... вроде бы - первоначальная проблема решена - ну, формально-то по описанию не повторяется! не, ну правда же! команда UCS_ROTATE_X заблокирована в блокэдите, и все путем... но есть нюанс. следующим ходом будет то, что кто-то воткнет в меню команду установки "среднепотолочно-удобной" системы координат. не сам придумал - отец научил - если надо посмотреть на модель вообще, то углы разворота (физический смысл - очень похоже на углы эйлера) - 17, 35, 7. это в градусах. это не абсолют - это именно среднепотолочноудобно. не понравится - доверни... но речь не о том. вот есть юзверь... ему надо что-то типа макроса - поверни мне UCS вот так. он знает, как работает (обычно) команда UCS. он честно пишет - где-то там, в кастомизаторе - что-то вроде UCS X 17 UCS Y 35 UCS Z 7 <и пробел>... и эта фигня ему 3 раза позовет команду UCS и сделает то, что он хотел. а можно просто из текстового редактора это скопипастить в комманд-лайн. это УДОБНО. - мы просто суем готовый кусок ввода. я не знаю как еще объяснить... ну удобно это! ясно даже и ежу (С) что если мы этот готовый кусок ввода воткнем невовремя - то нифига хорошего из этого не выйдет. насколько нифига - это как повезет... собственно, такой подход с одной стороны весьма гибок, а с другой - предполагает нечто вроде соглашения "добросовестного покупателя". то есть ты можешь в тот самый комманд-лайн швырять что угодно - но за контекст отвечаешь сам. равно как и за то, что нашвырял. и, опять-таки, возвращаясь к первоисточнику - возможно, я ошибусь, но исходный вопрос должен был ставиться не как "а фигли взлетает зум" - это я объяснил, и это (поверьте!) фигня... вопрос должен был стоять иначе - "фигли вы запретили менять UCS в блок-эдиторе?". вот на этот вопрос у меня ответа нет, кроме как "собезъянничали с АС" - и меня это тоже глубоко возмущает... а если у меня в блоке глубокое 3д, и мне без смены UCS грустно? в общем, не трогайте наш комманд-лайн, он не идеальный, но хороший... а вот как команды запрещали - это вопрос отдельный...
  10. на самом деле - все не совсем так. пространство модели - это необязательная фигня, которая как служит для визуального контроля того, что происходит. ну и упрощения ввода - в него тыкать можно иногда... а на самом деле - жужжит командный процессор, то есть, по сути, командная строка. она читает поток ввода (текстовый), нарезает его по неким правилам на кусочки и действует соответственно. в "спокойном" состоянии - ожидается команда (имя команды). когда введено нечто, на такое имя похожее - производится поиск команды по имени, и если она нашлась - то запускается. при этом, естественно, входной поток не сбрасывается - просто его обработку продолжает сама команда. она оттуда читает все, что ей захочется, потом заканчивается - и остатки входного потока читает опять командный процессор. что и как она будет читать - это целиком на совести команды. если команда не запустилась -по любой причине - то, естественно, то, что ей причиталось - она не съела, и это все доедает командный процессор. о том, что (предположительно) команда должна была съесть - он не знает ничего, ему это не интересно. почему команда ведет себя так, а не иначе - не его дело, это внутренняя кухня команды. можно спорить о плюсах и минусах подобного подхода, но он как минимум удобен - и прежде всего для пользователя, позволяя швыряться в командную строку целыми сценариями без всякого лиспа и проч.
  11. проблема как раз в том,что она НЕ выполняется, и кейворд, который она должна была съесть, съесть некому. соответственно, он воспринимается как другая команда... фактически, ситуация эквивалентна тому, что мы в команд-лайн кинули копипастом кусок текста. запрещенная команда в этом случае воспринимается как несуществующая, способа отличить внутрикомандный ввод от имени команды нет, и выкинуть ненужый остаток - мягко говоря затруднительно. но это я так, занудствую... что касается нашарика (ака локатор) - то он НЕ масштабируется вместе с объектами чертежа. размер локатора зависит от размера окна (точнее, рабочего поля) и это как раз вполне корректно и оправдано. я даже по секрету могу сказать - если окошко сделать совсем маленькое, то локатор тихонько спрячется, потому что натыкать что-то вразумительное на маленьком-маленьком локаторе тоже едва ли получится...
  12. в редакторе блоков зачем-то вообще запретили смену UCS. то есть вообще. зачем - вопрос отдельный, может быть в этом и есть какая-то логика, а может просто на всякий случай. а все остальное - это как раз следствие. мы кидаем (из меню, из ленты etc) команду UCS X (или UCS Z). в нормальной ситуации - запускается команда UCS и съедает кейворд (X или Z). в блок-эдиторе команда UCS *не запускается*, и кейворд воспринимается как отдельная команда со всеми вытекающими. такая вот хистория... UPD : возможно, запрет UCS просто собезьянничали с АС. там ровно такая же фигня...
  13. это глюк вполне конкретного печатного драйвера, и он жЫзнерадостно проявляется хоть при печати, хоть на превью - генератор геометрии-то один... более того, этот глюк проявляется только при наличии лайнтайпа - если поставить continous - то все становится нормально... куда глядеть примерно понятно, будем посмотреть!
  14. в общем, глюк интересный, но проблема действительно в самой полилинии. дело в том, что проблемный сегмент - это на самом деле дуга, просто очень большого радиуса. если его схватить за среднюю грипсу, то он тут же начнет тянуться именно как дуга... ну и для очистки совести - выставляем LUPREC=8, выбираем полилинию и зовем LIST. обращаем внимание на судорогу мозга в середине списка вершин, и видим, что у нас есть дуговой сегмент с какого перепуга оно рисуется неправильно - вопрос отдельный, но мне бы такая дуга тоже не очень понравилась!
×
×
  • Создать...