XHTML-IM support

[nk]

http://www.jabber.org/jeps/jep-0071.html

[nk]

consider using gecko (in gpe)

[nk]

gustavo tries to do xhtml/css subset that is recommened in JEP to texttags

for XHTML subset:

http://www.jabber.org/jeps/jep-0071.html#profile-summary

for what the style attribute can hold:

http://www.jabber.org/jeps/jep-0071.html#profile-style-properties RECOMMENDED:

• background-color
• color
• font-family
• font-size
• font-style
• font-weight
• margin-left
• margin-right
• text-align
• text-decoration

what those are http://www.w3.org/TR/REC-CSS1

[nk]

c also #781

[haks0r]

It's greate idea, Psi now support this JEP..

[sgala@…]

The patch adds the low level ability to insert a html fragment and parses

it in.

[sgala@…]

protocol changes for JEP-0071

[anonymous]

One too many, actually the tag is specified as "html" :)

 Index: src/common/xmpp/protocol.py
 ===================================================================
 --- src/common/xmpp/protocol.py (revision: 6795)
 +++ src/common/xmpp/protocol.py (copia de trabajo)
 @@ -399,7 +399,7 @@
          return self.getTagData('body')
      def getXHTML(self):
          """ Returns serialized xhtml-im body text of the message. """
 -        xhtml = self.getTag('xhtml')
 +        xhtml = self.getTag('html')
          return str(xhtml.getTag('body'))
      def getSubject(self):
          """ Returns subject of the message. """

[sgala]

The last patch, plus the htmltextview.py file and the

rst_html_generator.py are all of it.

Not adding the rst_html_generator and the changes with the related options should result in a version that can display xhtml-im but not generate it.

rst generation needs a patch sent upstream http://sourceforge.net/tracker/index.php?func=detail&aid=1561096&group_id=38414&atid=422032 to avoid common broken restructured text (say *error or bobby in irc) to break the generated markup. It is only relevant if plain text received from other people is marked up as rst (rst_formatting_other, default false).

[sgala]

Make it fully conformant with the spec (xml:lang in set/get body, several bodies)

[sgala]

new version, slight changes to get block markup right in lists

[sgala]

I could reproduce (but not understand) the problem some people was

experiencing.

It is due to not having libxml2 installed, and thus using expat.

My guess is that the problem is due to an exception in the contenthandler, which is reported in a weird way by the parser. I have a workaround in place (capture and use plain body), but further research is needed.

[dkirov]

libxml2 is required dependency by glade and cairo, so people who run gajim

always has this lib installed.

[sgala]

It could be the libxml2 version. The real question is:

• Now I can reproduce
• Even better, I found the cause is the xhtml string being passed to the htmlviewer is Unicode (does not matter if it contains non-ascii characters or not). Looks like the python-C interface *cares* about char[] vs short[] vs int[] (depending about one uses utf-8, ucs-2 or ucs-4)
• A upgraded patch with the solution plus other changes is on its way up to the server

[sgala]

yet another version, closer to the requisites for integration, I hope

[sgala]

New version.

I splitted the patches so that they can be applied incrementally.

• xhtml-im-display.patch is the basic protocol, htmlview and gajim support for displaying incoming xhtml-im messages. It should work as usual, except where users (pyirc-t, other clients) are already sending html. It does not generate it.

• xhtml-im-outgoing.patch support for using docutils' reStructured text for xhtml generation. with an ACE option rst_formatting_outgoing_messages, initially false. Includes the rst generation class, plus hooks to generate messages before they are sent.

The next two, I have serious doubts if they should be applied. I used them for testing, but I'm not sure they are a good idea to release them:

• xhtml-im-incoming.patch Optionally (rst_formatting_incoming_messages, False), pass incoming messages through the generator. It would give a similar formatting to current gajim, except if people uses rst explicitly or for more complex blockmarkup (lists, pre, blockquote, ...)

• xhtml-im-history.patch Optionally (rst_formatting_history_messages, False), view history messages using rst generation. It is mostly slow, as it converts each line in the log before viewing it. I think that storing optionally received/sent xhtml in the logs, in addition to text/plain, would be a better idea.

I'm uploading those, using the names here. They need to be applied in the given sequence.

[sgala]

patch for generation of xhtml-im using the restructured text parser for log entries (requires docutils and the previous patches)

[sgala]

patch for basic xhtml display support (re-diffed)

[sgala]

patch for generation of xhtml-im using the restructured text parser (requires docutils and the previous patch)

[sgala]

generation of xhtml-im using the restructured text parser for incoming messages

[anonymous]

Replying to nk:

> http://www.jabber.org/jeps/jep-0071.html

[asterix]

display and outgoing are in ! Thanks a lot Santiago Gala !

I leave open for some minor things (capabilities part of JEP, and a TODO in xmpppy/protocol.py)

[nk]

can we avoid or we should demand docutils

[sgala]

The last patch should avoid the dependency on docutils unless the user

selects rst_formatting_ongoing_messages.

Also, this option should not be allowed to be selected if "import docutils" throws an exception (maybe in config, not sure)

[sgala]

The current version of the patch does a better job.

If docutils can't be imported, a null generator is used, that always returns None (to avoid sending plain text xhtml parts).

This opens a way to have different generators using different markup/UI techniques to generate the xhtml-im part.

[sgala]

another try to avoiding problems if docutils are not present

[sgala]

section 10.1 of JEP (disco info response)

[sgala]

fiexs the "double isolated emoticon" and the "no whitespace" problems

[asterix]

(In [7262]) [sgala] fix dubble emoticon in htmltextview when receiving xhtml message. see #316

[asterix]

this ticket can be closed now, thing that remain: option to disable xhtmltextview, see #2522