KTextEditor && richtext (Re: [Design] New composer.)

Vadim Plessky lucy-ples at mtu-net.ru
Sun Dec 1 15:13:14 GMT 2002

On Sunday 01 December 2002 4:18 pm, Marc Mutz wrote:
|  On Sunday 01 December 2002 08:43, Zack Rusin wrote:
|  <snip>
|  > interface in the KTextEditor : RichTextInterface. RichTextInterface
|  > might sound scary but all it adds is : setFont, setColor, setSize,
|  > setItalic, setBold, QString htmlText and QString asciiText. I think
|  > that's all we'd need for our purposes.
|  I'm still of the opinion that we should start with text/enriched
|  composing instead of text/html. If font, bold, italic, size and color
|  are the only attributes of text (we'd need at least <tt>, too!) anyway,
|  then text/html is overkill. t/enriched can do all that plus horizontal
|  alignment.

What about 'image/xml+svg' (SVG) than?
You can go to Tiny SVG or SVG Mobile profile, there is no need in scripting 
for your particular application (KMail)

|  For rich text in emails, the most important things are (in order of
|  importance):
|  1. bold, italics and underline (*bold*, /italics/ and _underline_)
|  2. fixed and proportional font (ascii art vs. flowed text)
|  2a. lists (bullet and ordered)
|  3. horizontal alignment (    this is centered    )
|  4. left/right margin
|  5. size
|  6. color
|  7. font

what about lists?
Lists are quite handy.

|  (2/2a) can even be expressed in text/plain format (2: format=flowed
|  only), while everything but (I guess) margins can be expressed in
|  t/enriched.
|  If KMail send HTML-mails, then people are softly forced to accept html
|  mail. That's a big step backwards in perceived security of KMail.

what about 'multipart/alternative' mail format (hope I have spelled it right)
If you get mail with both text/plain and text/html (and even with 
image/xml+svg), than it's up to user preferences - wether to render mail 
using HTML, or display SVG or just plain text.

BTW: I think sending mails in SVG is really cool! :-)
We will beat both Apple and MS with such feature. I doubt MS palnned something 
like this for Longhorn release (scheduled for 2004 or even 2005)

|  The only problem I see with KTextEdior is that we (KMail) should
|  automatically choose the right format. If people are forced to choose
|  between html, t/enriched and plain text, they will choose poorly.
|  KMail can try to send t/p, t/e and t/h in that order, transparently
|  adding mp/alternative for at least t/h.

Sounds good to me.
I think KMail should defualt to plain text for mailing lists,and to 
mp/alternative with t/p and t/h at least.

about text/html:
I think XHTML Basic+CSS should be used (not HTML, not XHTML 1.0, 1.1).
Than none wopuld say that KMail sends crappy HTML.
XHTML Basic was designed with mobile phones in mind (I am not aware of any 
mobile phones which supports it, though), so it can be that users with mobile 
phones would be able to read such mails.

|  KTextEditor doesn't seem to provide an interface to access the markup
|  from the outside. So how about adding a visitor interface:
|  > Comments?
|  Marc


Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
My KDE page
http://kde2.newmail.ru  (English)
KDE mini-Themes

More information about the kde-core-devel mailing list