[Kde-pim] Newlines in QTextDocument

Thomas McGuire mcguire at kde.org
Tue Feb 24 11:23:31 GMT 2009


Hi Stephen,

On Monday 23 February 2009 18:03:38 Stephen Kelly wrote:
> You may be aware that there are a few bugs regarding newlines in
> QTextDocument.
>
> One is this:
> https://bugs.kde.org/show_bug.cgi?id=180207
>
> (Can we have a list of the others. Even the closed ones. I want to have one
> solution to this issue)

Ok, here the KMail list, after a bit of searching:

Extra line break after sending message: 
https://bugs.kde.org/show_bug.cgi?id=86925 (this one has many duplicates, and 
I think is solved by the hacky fix in r856835)

Less line breaks after sending message (opposite of the above, it seems): 
https://bugs.kde.org/show_bug.cgi?id=173877

When opening HTML draft, empty lines are tripled: 
https://bugs.kde.org/show_bug.cgi?id=180612

Not related to linebreaks, but to RTL in the composer: 
https://bugs.kde.org/show_bug.cgi?id=181311

Even more unrelated (happening in plain text version): Wordwrapping broken 
after opening a draft: https://bugs.kde.org/show_bug.cgi?id=105532

> One solution that was proposed was to remove the line of paragraph style
> from the html output of document->toHtml. That's what's done in
> KRichTextEdit, but I don't remember who put it there:
>
> http://websvn.kde.org/trunk/KDE/kdelibs/kdeui/widgets/krichtextedit.cpp?vie
>w=markup

Looks like it was me who put it there, see 
http://websvn.kde.org/trunk/KDE/kdelibs/kdeui/widgets/krichtextedit.cpp?view=log#rev856835 

> I don't think it solves all the problems, and I don't think it's a great
> solution. If that was unneeded, Qt would not have put it there. I think
> it's there so that the document survives round trips through QTextDocument
> the exact same.

Yes, it's a hack. I'd like to have something nicer, but at least this hack 
solves one of the most annoying KMail HTML bugs. Not sure about the 
roundtrips, right now it appears that after doing a roundtrip via saving a 
mail as draft, the textedit has too many linebreaks, not too less.

> Another solution was to create a system for creating wholly nicer html from
> the QTextDocument.
>
> http://websvn.kde.org/trunk/KDE/kdepimlibs/kpimidentities/richtextbuilders/
>
> That also doesn't solve the newlines problem though. Additionally, I'm
> going to have to change the API of the Director and Builders to make it
> more flexible, so the headers can't be installed yet.

Well, I'm sure we can at least add hacks to the newline problem, by producing 
nicer HTML and maybe by having a custom setHtml() method.
For the whole richtextbuilders stuff, I still want to move some parts of 
KMeditor and KMComposerEdtior to a new textedit library in kdepimlibs, which 
would also use the richtextbuilder stuff. Moving it to kdepimlibs is needed 
for getting support for inline images in HTML signatures. But I've not found 
the time to do so, yet.
FWIW, I've also put this as part of a SoC project on the wiki, see 
http://techbase.kde.org/Projects/Summer_of_Code/2009/Ideas#Project:_Improvments_in_KMail.27s_HTML_support

> What we need is some tests with qtextedit to make sure that:
> * HTML Documents survive round trips through QTextDocument with the same
> number of newlines.
> * Browsers also render the generated document correctly.
> * Documents created in a QTextEdit also adhere to the above.
> * Documents exported into QTextEdit (with its limited html support) can be
> exported with the correct number of newlines.
> * The exported html should be standard and well defined html. Note that the
> patch I made to Qt does not make valid html according to ogoffart (link
> below)
>
> I think this is mostly a html and css issue.
>
> Ahmed has done some investigation, so I hope he will post here too.
>
> Other interesting links:
>
> http://www.nabble.com/New-qt-patch.-Can-it-go-into-qt-copy--td20368821.html
> http://lists.trolltech.com/qt-interest/2008-11/thread00279-0.html
>
> At this point, I think the most valuable thing we can get is some test
> cases and information on what 'valid html' is around newlines etc.
> Unfortunately the closing </p> tag is optional, and I think that causes
> headaches.
>
> I can do coding work on this, but I need answers to the above so I know
> what to export. I can't do much of that sort of investigation work though
> as I'm currently travelling.

For the tests, the KMail case would be:
- Preserve linebreaks after saving from draft and opening that draft
- After composing the message, the linebreaks, as displayed by KHTML, should 
  be the same as they appeared in the composer.

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090224/78ca9923/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list