It appears to be an issue with the import tool. Kopete escapes the HTML by replacing opening "<" by "&lt;" to prevent the tag from being interpreted as part of the XML document.

The proper solution would be to drop the HTML tags completely when importing the message, but there's always the risk of false positives. I'm afraid that unescaping "&lt;" back to "<" could break Adium themes.

However since this corrupted logs have already been imported, I guess a workaround will be needed in LogViewer as well.

Dan, Have you got any ideas on how we can safely fix this?

I don't.

No. I think we will have to choose the least evil approach of the two I mentioned in comment #1. I think that converting "&lt;" to "<" is safer, since it can only break visual representation, but not the data itself.

But I'm opened to any suggestions :-)

We can fix new imports,  but not fix what's already there like that.

Otherwise any HTML I've sent you in the past would be rendered not shown as HTML tags in the UI.

Ok, it appears that in Kopete logs, any HTML written by user is completely escapes (i.e. both < and > are escaped as &lt; and &gt;), while a generated HTML has only the opening tag escaped:

&lt;p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Paragraph in HTML is enclosed in &lt;p&gt; and &lt;/p&gt; tags.&lt;/p>

I suck at regular expressions, so could someone help me please with this please?  ;-)

I'm confused, what's your plan?

I thought that during import we would either remove or unescape the <p....> tags, while keeping the user's HTML escaped.

So fixing the import bug, not fixing imported data.  That should be fine.

and we want to match
<p  *junk* >  *important text*    <p>
and replace it with *important text* ?

are the <p> tags always at the start and end of the string? or can we have multiple per message?

Can we store somewhere the version that made the import after importing, so that if we know that logs were imported with a buggy version we can try recovering them?

No, as logger isn't controlled by us.

I mean when our log importer runs, we could store a setting, and when the log-viewer is executed we could read that setting and eventually try to fix the import.
Oh but perhaps you mean that we cannot modify logger data...

@David:
Yup, exactly. I'm pretty much sure that it only appears once and wraps the entire message. However as you can see in the first comment, there's also a wrapping <span> tag that might appear in some messages. 


@Daniele:
We don't need control over TpLogger. We could simply iterate through all existing log files and "fix" them. The importer does not use TpLogger at all, it creates the .xml files and stores them into ~/.local/share/TpLogger/...

Git commit e469dfe3d6bcd02b7c0ffd8e513fa2a9d0face0e by Dan Vrátil.
Committed on 13/05/2013 at 14:04.
Pushed by dvratil into branch 'kde-telepathy-0.6'.

Strip wrapping HTML tags when importing logs from Kopete

Also disable check whether the logfile already exists in TpLogger and
just overwrite it. This allows users to reimport their Kopete logs
FIXED-IN: 0.6.2
Reviewed-By: David Edmundson

M  +11   -7    KTp/logs-importer-private.cpp

http://commits.kde.org/telepathy-common-internals/e469dfe3d6bcd02b7c0ffd8e513fa2a9d0face0e

Does that reimport mean that as I impoerted logs with html tags, these will be replaced by newly imported logs without html tags? That's awesome.

(In reply to comment #14)
> Does that reimport mean that as I impoerted logs with html tags, these will
> be replaced by newly imported logs without html tags? That's awesome.

Yes, all imported logs will be overwritten with new ones without the HTML tags. You can run the importer manually from Log Viewer -> Logs -> Import Kopete Logs