Удалить форматирование текста autocad
Обновлено: 07.07.2024
Как кстати, а я уже некоторое время подумывал не спросить есть ли у кого-нибудь готовое решение для борьбы с форматированием.
Есть такие вопросы и пожелания
1. Неплохо бы откат заиметь (коль уж это готовая программа).
2. В следующем примере у меня удалилось не все форматирование:
до применения функции:
3. А в текстах с фигурными скобкаи количество накладок еще прирастает (в данном примере Acad даже ругаться начинает при попытке редактирования):
до:
Так а все правильно - все дело в том, что по идее для многострочного текста символы "" являются служебными, обрамляющими форматирование, насколько я понял. Можно, конечно, снять это дело, и обращаться только к частям "\\f" и ";" (который идет после "\\f" и означает окончание описания фонта), но тогда гарантированно будут оставаться символы ">".
п.1: вот вариант с глобальным откатом для вызовов unf-all и unf-sel (я прошу прощения, упустил как-то из виду) - код просто заменить:
п.2 Форматирование вида \h2x не является форматированием шрифта, оно задает только высоту следующего текста. Поэтому и не сносится.
п.3. А что там должно быть изначально-то?
Смотри логику поведения - полужирным выделено сносимое. для удобства еще и на разные строки разбил ;)
Так что в принципе все правильно - надо либо сносить лишние "\", либо как-то еще выкручиваться - например, в функции _kpblc-clear-mtext на моменте назначения sub_pos поиграться с выбираемыми моментами. Только тут надо учесть, что просто "\\" сносить низзя - таким манером еще и подчеркивание, бывает, назначается.
Хотя стоп, насчет \H2x я, похоже, погорячился. Как в таком варианте поступать - даже не представляю.
> kpblc
Не знаю на счет \H2x, но ребята чертежники доходили до того, что применяли даже Explode (когда нет времени редактировать каждый мультитекст), чтобы исправлять стили шрифта. Попробовал твою прогу - экономит кучу времени. Многократно не тестировал, пока нам подходит, спасибо.
> kpblc
по п.1 Есть мнение, что если после
(vla-startundomark *kpblc-activedoc*)
произойдет ошибка (например если попадется
текст на заблокированном слое)
то (vla-endundomark *kpblc-activedoc*) не сработает
и при оставшейся открытой метке теоретически возможна
ситуация, когда при вызове undo откатит так, что
мало не покажется. Поэтому либо ставить обработчик,
либо перехват, либо вообще не ставить меток.
(мне так кажется)
по п.3
Если на экране текст выглядит так
то в идеале хотелось бы чтоб после "очистки" он выглядел
так (не на экране, а "внутри")
т.е. чтоб из связки \< не проподала фигурная скобка
Впрочем фигурные скобки в текстах относительно редки,
я их вставил исключительно для теста, и с этим можно мириться.
зы касательно \< выяснился нежелательный момент -
при EXPLODE текст все равно взрывается в "труху" именно в начале
и в конце скобки. Т.е. столь желательный эффект корректного EXPLODE
в отсутствии форматирования пропадает :(
> AY
Ну ты уж реши - либо нужны метки, либо нет ;) Хотя на самом деле перед первой меткой можно поставить (vla-endundomark) - оно закроет все открытые метки. Правда, тогда *kpblc-activedoc* придется делать глобальным, что в данном варианте в принципе не помеха.
"Обрамления" unf-all и unf-sel на самом деле лично у меня нет - я все равно это делаю сразу на весь файл, вызывается внутри другой функции, которая еще из одной вызывается, и вот только в последней у меня уже все - и отлов ошибок, и закрывание меток отмены, и восстановление системы.
Насчет заблокированного слоя тоже не проблема обойти (причем не внутри цикла, чтобы не загружать машину впустую).
Насчет связки "\\" - в принципе, сделать можно. Если сильно надо, сделаю, только уже явно не сегодня - не поспеваю. И сюда же: мне не удалось (ADT 2005 Eng + SP1, mtexted - любое значение, специально проверил) повторить "в труху". Если втупую колотить текст
то символы < и >на экране не отображаются (для внешнего редактора), да и в кодах нет такой пары "\"). Стоит поставить \< (\>) в тексте внешнего редактора, как скобки начинают отображаться, но в кодах появляются связки "\\". В общем, тут совсем темный лес. Как таковой пары \< нет.
Читайте также: