Редактирование размера текста RTF

Добрый день.
Есть содержимое текста формата rtf, нужно узнать его размер шрифта, и изменить его.
Сейчас приступил к поиску информации, одновременно создав тему.
Помогите найти решение и сэкономить времени)

Добавлено через 22 часа 13 минут
але ап

0

skilllab, а как же ты добавил этот смайлик, не редактируя сообщение... ох вейт

Сообщение от skilllab значит как Fody в WPF накатывать на каждый чих - это норм)) ? Или целый Reactive для для создания отзывчивой коллекции (вместо написания одного класса) - тоже норм? Тогда я запутался

На каждый чих - не норм. Своему инструменту - своя область действия, очевидно.

0

Сообщение от Psilon Своему инструменту - своя область действия

Ну так...если кто-то начинает устанавливать целые фреймворки ради достижения незначительной (единичной, локальной) цели, чего ж там (в топиках) никто не "фукает"? Чего к этому прицепились?

0

skilllab, мне вообще пофиг, я обосновывал мнение товарища Usaga. Тем более, что я заранее сказал, что его позицию считаю чуть более слабой Но не дело так рьяно не соглашаться с альтернативной тз

0

Я против такого подхода потому, что это - фигня с точки зрения архитектуры и здравого смысла. То, что этот контрол идёт в комплекте с .NET ещё не значит, что его нужно вот так вот использовать.

Psilon, diadiavova, я понимаю, что если оно есть и как-то работает, по "чёбы нет?". Это тоже самое (для меня, по крайней мере), что использовать split() для посчёта слов в строке (наверное я уже достал всех этим примеом).

diadiavova, что бы что-то считалось хреновой практикой, оно не обязательно должно крашить приложение и баги какие-то вызывать. И пример с офисом я нахожу хорошим - он демонстрирует мою мысль: у всего своё предназначение и использовать что-то в сценариях, для которых оно не было рассчитано - беспонтовый костыль.

Речь-то пошла про данный контрол почему? Не потому, что он отлично подходит под задачу, а просто потому, что он есть в .NET (и, получается, пофиг, что является частью UI-фреймворка). Лично я бы не стал рассматривать такой вариант даже, если бы писал WF-приложение. Это контрол. Пускай контролит. Не нужно делать всякую фигню просто потому, что можно и приложение не крашится. Пожалуйста.

Достаточно пять минут погуглить какую-нибудь библиотеку для работы с RTF и использовать её.

Добавлено через 1 минуту
Конечно же это всё чисто моё мнение и вы вольны категорично не согласиться.

0

Сообщение от Usaga Я против такого подхода потому, что это - фигня с точки зрения архитектуры и здравого смысла.

Представления о здравом смысле у всех разные. Мне вот, например, здравый смысл подсказывает, что если нужен некий функционал, который предоставляет некий класс, существующий во фреймворке, то надо его использовать. У тебя другое представление. Будем спорить о том чей смысл более здравый? Думаю это бесперспективно.
А вот об архитектуре - поподробнее, если можно, поскольку я здесь не вижу никаких проблем.

Сообщение от Usaga Это тоже самое (для меня, по крайней мере), что использовать split() для посчёта слов в строке (наверное я уже достал всех этим примеом).

А со сплитом-то что не так?

Сообщение от Usaga что бы что-то считалось хреновой практикой, оно не обязательно должно крашить приложение и баги какие-то вызывать.

А что для этого нужно и что из того что нужно присутствует в данном случае?

Сообщение от Usaga И пример с офисом я нахожу хорошим - он демонстрирует мою мысль

Насчет офиса я объяснил в чем разница: такой подход влечет вполне конкретные проблемы, в отличие от библиотек фреймворка. Именно поэтому пример с офисом ничего не иллюстрирует.

Сообщение от Usaga у всего своё предназначение и использовать что-то в сценариях, для которых оно не было рассчитано - беспонтовый костыль.

С костылем согласен, с беспонтовым - нет. Беспонтовым он был бы, если бы не решал задачу. Что касается того, что для чего рассчитано, то, насколько я понимаю, что такое фреймворк, его классы должны быть максимально универсальными и если им находится дополнительное применение, то это скорее плюс, чем минус.

Сообщение от Usaga Речь-то пошла про данный контрол почему? Не потому, что он отлично подходит под задачу

И поэтому тоже, кстати. Могу пояснить, если есть желание. Я, обычно, если на чем-то настаиваю, то могу пояснить конкретно, почему я так считаю.

Сообщение от Usaga а просто потому, что он есть в .NET

Да, и это приводит к тому, что не приходится тянуть неизвестно что, неизвестно кем написанное и неизвестно какие сюрпризы готовящее.

Сообщение от Usaga и, получается, пофиг, что является частью UI-фреймворка

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

Сообщение от Usaga Это контрол.

Это прежде всего класс и предоставляется для решения тех задач, которые он умеет решать, независимо от того насколько полно используется его функционал.

Сообщение от Usaga Не нужно делать всякую фигню просто потому, что можно и приложение не крашится.

А этого никто и не предлагает. Я предложил решать с его помощью поставленную задачу на основании того, что он с ней справляется и не влечет никаких негативных последствий. Все-таки это не совсем то, что написал ты.

Сообщение от Usaga Достаточно пять минут погуглить какую-нибудь библиотеку для работы с RTF и использовать её.

Вопрос в том, что ты в результате нагуглишь.

Сообщение от Usaga Конечно же это всё чисто моё мнение и вы вольны категорично не согласиться.

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

0

Сообщение от diadiavova Я готов согласиться, если это будет убедительно обосновано, но покамест я вижу, что все представленные возражения имеют сугубо эстетический характер.

Речь о контроле из фреймфорка Windows Forms (да, это отдельный фреймворк, просто идущий в комплекте с .NET). Использование данного контрола для обработки RTF может быть оправдано только при разработке приложения под WinForms. Да и то, так себе решение.

В случае же другого типа приложения (консоль, веб-приложение, WPF или служба) обращаться к WF за контролом для обработки документа... плевок в архитектуру приложения. Я не понимаю, почему для вас такое - норм. Для меня это выглядит как сборка из говна и палок подручных материалов: до чего дотянулись, то и приладили. Работает же.

Пример с офисом про неуместное использование. Я так понимаю, что если бы офис обязательно стоял бы у всех, то с ним была бы та же ситуация, что мы рассматриваем сейчас. Ну а что? Оно уже есть в комплекте?

Сообщение от diadiavova А со сплитом-то что не так?

Вы серьёзно?

0

"Использование данного контрола для обработки RTF может быть оправдано только при разработке приложения под WinForms. Да и то, так себе решение."
Вспомнилось тут ещё вот что: как по вашему, то тянуть целую либу visual basis для того, чтобы обрезать строку слева или справа, вместо написания своих методов на шарпе - это тоже плохо?

Добавлено через 3 минуты
Типа Left() на vb

0

Сообщение от skilllab тянуть целую либу visual basis для того, чтобы обрезать строку слева или справа, вместо написания своих методов на шарпе - это тоже плохо?

Нет, ведь оно для этого и предназначено.

0

Сообщение от Usaga Использование данного контрола для обработки RTF может быть оправдано только при разработке приложения под WinForms.

Один вопрос, который я задаю на протяжении всей темы: ПО-ЧЕ-МУ?

Сообщение от Usaga В случае же другого типа приложения (консоль, веб-приложение, WPF или служба) обращаться к WF за контролом для обработки документа... плевок в архитектуру приложения.

Насчет архитектуры я в предыдущем посте попросил пояснить и объяснил, что никаких проблем с архитектурой в данном случае не вижу.

Сообщение от Usaga Я не понимаю, почему для вас такое - норм.

Это я тоже уже объяснил неоднократно: это решает проблему наиболее простым способом и не влечет негативных последствий.

Сообщение от Usaga Для меня это выглядит как сборка из говна и палок подручных материалов: до чего дотянулись, то и приладили. Работает же.

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

Сообщение от Usaga Я так понимаю, что если бы офис обязательно стоял бы у всех, то с ним была бы та же ситуация, что мы рассматриваем сейчас. Ну а что? Оно уже есть в комплекте?

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

Сообщение от Usaga Вы серьёзно?

Я так понимаю, это тоже "фу" ))

0

diadiavova, потому, что использовать контрол для обработки и хранения RTF документа - это неправильное использование контрола. Правильное - выводить данные пользователю (ну и разреать редактировать, раз уж оно так умеет). Это его контрольная натура.

Сообщение от diadiavova Дело не только в комплекте, а еще и в том, что это чрезвычайно сложный формат данных и лучше родной библиотеки с ним ничто не справится. Смотрел бы по ситуации, но в общем и целом ничего не имею против такого подхода.

Чего-то подобного я и ожидал услышать.

Сообщение от diadiavova Я так понимаю, это тоже "фу" ))

Да.

Я пытаюсь донести мысль, что поступать так можно только, если это обусловлено какой-то жёсткой необходимойстью. Вот ну нельзя подругому (или некогда - сдавать проект нужно полчаса назад). Это понятно и простительно.

Но считать такое нормой нельзя. Это путь к помойке в коде. Потому, что допустимо станет сразу куча разных других вещей: нужно посчитать что-то в строке? Split()! Нужно с документом EXСEL работать? Обяжем пользователя ставить офис и будем дёргать через Interop, передать параметры в запрос? Concat-им в строку и вроткомпот. Ну и так далее.

Вы не допускаете использование контрола для обработки документов здесь и сейчас. Вы допускаете дерьмовые решения в принципе, везде и всюду. Это страшнее плохой архитектуры.

0

Сообщение от Usaga Я пытаюсь донести мысль

Да это-то не проблема... обосновать, видимо, уже сложнее.

Сообщение от Usaga Обяжем пользователя ставить офис и будем дёргать через Interop, передать параметры в запрос?

Я как-раз, вроде как, настаивал на том, что чем меньше программа за собой тянет - тем лучше. Нэ?

Сообщение от Usaga Вы допускаете дерьмовые решения в принципе, везде и всюду.

Ну почему же везде и всюду. В некоторых местах вполне допускаю, например в каких-то мелких вспомогательных программах одноразового применения. Но в основном дело не в том, что я допускаю дерьмовые решения, просто для того чтобы я признал решение дерьмовым мне нужно убедительное обоснование. А то, что оно кому-то кажется "фу", а почему "фу" он сам не знает - меня не убеждает. Для меня то решение дерьмовое, от которого могут быть дерьмовые последствия. Здесь я этого не увидел, поэтому продолжаю считать такое решение хорошим.

0

diadiavova, ну ОК.

0