Hello,
is anybody aware of the fact that when talking to Pidgin users Jitsi will display HTML/RTF formatting tags inside the text messages? Is this a problem of Pidgin, and what could be done about it?
BR FLorian
Same problem with Adium which is based on libpurple. Jitsi does not know how to interpret font styles
···
On 2015-02-18 11:33, flori@bin.org.in wrote:
is anybody aware of the fact that when talking to Pidgin users Jitsi
will display HTML/RTF formatting tags inside the text messages? Is
this a problem of Pidgin, and what could be done about it?
Hey Florian, Jackson,
Could you send some more details on which chat protocol, whether or not you
are using OTR when it happens and maybe a screenshot showing the problems,
so we can see the extent of it?
That would really help. I have noticed something similar in case where OTR
is active, but I'm not sure if you are talking about the same thing.
Danny
···
On Wed, Feb 18, 2015 at 3:12 PM, Jackson D <jacksond@openmailbox.org> wrote:
On 2015-02-18 11:33, flori@bin.org.in wrote:
is anybody aware of the fact that when talking to Pidgin users Jitsi
will display HTML/RTF formatting tags inside the text messages? Is
this a problem of Pidgin, and what could be done about it?Same problem with Adium which is based on libpurple. Jitsi does not know
how to interpret font styles_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
Hej Danny,
It is only when OTR is used.
It happens at least for me on XMPP and Yahoo IM.
It happens when the non jitsi user has a custom theme which changes fonts - or at least of the people I have this problem with it has been the case that the use a theme.
Messages show up like such
<FONT FACE="Lucida Grande" ABSZ=12 SIZE=3>text goes here.</FONT>
With otr off, in this instance I get green text from that user
···
On 2015-02-18 14:16, Danny van Heumen wrote:
Could you send some more details on which chat protocol, whether or
not you are using OTR when it happens and maybe a screenshot showing
the problems, so we can see the extent of it?
I can confirm this also. It´s only in OTR, which I have automatically set for this user, so I did not notice immediately.
See attachment for an example without and with OTR... the green text on the beginning was without OTR...
From Pidgin it looks similar also like this:
<font color="#D75E5E">asfdsdfsfasdfas jetzt is sie rot </font>
<font color="#D75E5E">hellrot </font>
BR Florian
Zitat von Jackson D <jacksond@openmailbox.org>:
···
On 2015-02-18 14:16, Danny van Heumen wrote:
Could you send some more details on which chat protocol, whether or
not you are using OTR when it happens and maybe a screenshot showing
the problems, so we can see the extent of it?Hej Danny,
It is only when OTR is used.
It happens at least for me on XMPP and Yahoo IM.
It happens when the non jitsi user has a custom theme which changes fonts - or at least of the people I have this problem with it has been the case that the use a theme.Messages show up like such
<FONT FACE="Lucida Grande" ABSZ=12 SIZE=3>text goes here.</FONT>
With otr off, in this instance I get green text from that user
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
-----
Anhänge (Links laufen am 31.08.2015 ab):
1. Jitsi-01.png (39 KB) [image/png]
Herunterladen: https://rooty.bin.org.in/horde/imp/attachment.php?id=54e4a5c6-9098-4775-9517-1fa3253b6c84&u=flori%40bin.org.in
This is a problem with the OTR plugin for Pidgin. Many other OTR-enabled clients (like Miranda, IM+, etc.) have this problem when talking to Pidgin/Adium.
I believe there was a ticket for Pidgin but it was closed as invalid because the OTR plugin is not part of the official Pidgin distribution.
Regards,
George
···
On 18 Feb 2015, at 15:47, flori@bin.org.in wrote:
I can confirm this also. It´s only in OTR, which I have automatically set for this user, so I did not notice immediately.
See attachment for an example without and with OTR... the green text on the beginning was without OTR...
From Pidgin it looks similar also like this:
<font color="#D75E5E">asfdsdfsfasdfas jetzt is sie rot </font>
<font color="#D75E5E">hellrot </font>BR Florian
Zitat von Jackson D <jacksond@openmailbox.org>:
On 2015-02-18 14:16, Danny van Heumen wrote:
Could you send some more details on which chat protocol, whether or
not you are using OTR when it happens and maybe a screenshot showing
the problems, so we can see the extent of it?Hej Danny,
It is only when OTR is used.
It happens at least for me on XMPP and Yahoo IM.
It happens when the non jitsi user has a custom theme which changes fonts - or at least of the people I have this problem with it has been the case that the use a theme.Messages show up like such
<FONT FACE="Lucida Grande" ABSZ=12 SIZE=3>text goes here.</FONT>
With otr off, in this instance I get green text from that user
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users-----
Anhänge (Links laufen am 31.08.2015 ab):1. Jitsi-01.png (39 KB) [image/png]
Herunterladen: https://rooty.bin.org.in/horde/imp/attachment.php?id=54e4a5c6-9098-4775-9517-1fa3253b6c84&u=flori%40bin.org.in_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
Additionally strange information:
- German Umlauts work
- these dont work:
- Double quotes
- < and >
will be for example:
"
<
>
etc.... it seems that all possible reserved characters from XML/HTML
standard wont work?
BR Florian
···
Am 18.02.2015 um 16:46 schrieb George Politis:
This is a problem with the OTR plugin for Pidgin. Many other
OTR-enabled clients (like Miranda, IM+, etc.) have this problem when
talking to Pidgin/Adium.I believe there was a ticket for Pidgin but it was closed as invalid
because the OTR plugin is not part of the official Pidgin distribution.Regards,
George
Hi all,
The effect is very simple to explain: You are receiving an
HTML-formatted instant message.
The cause is also fairly easy to understand. Jitsi can't determine what
message type it receives and defaults to plain text. Pidgin can't
express what message type it's sending and defaults to HTML.
So, basically this is just an unfortunate mismatch.
This is caused by OTR, because the OTR data is sent in plain text, and
*that* is the message that Jitsi/Pidgin receives. I do not think there
is a way to express what the *decrypted* message content type is. I had
a quick look at this a few weeks ago and that was as far as I got with this.
The other way around also works, i.e. if you send a message containing
some html, then Pidgin will parse this. For example "<b>Dude</b>,
<i>sweet!</i>" should show as formatted text in Pidgin. This is the
result of the same issue but in reverse. (Pidgin doesn't execute
<script> though 
One solution to this is to use some heuristic to scan the content and
determine whether or not the content is html-based. Another is to try
and find out whether the other client is using Pidgin. (I believe
there's some identifier in OTR we can use for this, I'm not sure.) Yet
another would be to find some identifier signaling HTML content *inside*
the message. Maybe like an <html> header or something.
I haven't got a solution for this yet, though.
Regards,
Danny
···
On 18-02-15 19:19, Florian Leeber wrote:
Additionally strange information:
- German Umlauts work
- these dont work:
- Double quotes
- < and >will be for example:
"
<
>etc.... it seems that all possible reserved characters from XML/HTML
standard wont work?BR Florian
Am 18.02.2015 um 16:46 schrieb George Politis:
This is a problem with the OTR plugin for Pidgin. Many other
OTR-enabled clients (like Miranda, IM+, etc.) have this problem when
talking to Pidgin/Adium.I believe there was a ticket for Pidgin but it was closed as invalid
because the OTR plugin is not part of the official Pidgin distribution.Regards,
George_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
Hi Danny,
understood, but... why is it different when OTR is off? Is there a
change in content designation or how does this work? Sorry that I am not
familiar with all the standards right now...
BR Florian
···
Am 18.02.2015 um 21:44 schrieb Danny van Heumen:
Hi all,
The effect is very simple to explain: You are receiving an
HTML-formatted instant message.
The cause is also fairly easy to understand. Jitsi can't determine what
message type it receives and defaults to plain text. Pidgin can't
express what message type it's sending and defaults to HTML.So, basically this is just an unfortunate mismatch.
This is caused by OTR, because the OTR data is sent in plain text, and
*that* is the message that Jitsi/Pidgin receives. I do not think there
is a way to express what the *decrypted* message content type is. I had
a quick look at this a few weeks ago and that was as far as I got with
this.
Hi Florian,
Hi Danny,
understood, but... why is it different when OTR is off? Is there a
change in content designation or how does this work?
Well, it's like this. XMPP (I only know for the XMPP case) supports
adding some kind of content type to explain how the message should be
interpreted. However, since we transmit an OTR-encrypted message, the
content type is used to interpret the OTR-encrypted message content,
which is plain text.
Now, when the message is decrypted, we end up with some plain bytes and
we don't have any headers associated with that, so we can't determine
it's content type.
In short: OTR adds an extra layer and for this extra layer we do not
have all the necessary meta data.
... or at least, that's what it looks like at the moment. Like I said, I
might come to other conclusions when I look into this some more, but I
am afraid we may end up guessing the content type by scanning the
content. This would suck, because it would mean that if you type in some
html tags as part of your message, then Jitsi might decide it's now HTML
content - even though it might not be the case.
Sorry that I am not familiar with all the standards right now...
It's okay. I learned that only a few weeks ago from reading the source
code and the specs.
Danny
···
On 18-02-15 22:29, Florian Leeber wrote:
BR Florian
Am 18.02.2015 um 21:44 schrieb Danny van Heumen:
> Hi all,
>
> The effect is very simple to explain: You are receiving an
> HTML-formatted instant message.
> The cause is also fairly easy to understand. Jitsi can't determine what
> message type it receives and defaults to plain text. Pidgin can't
> express what message type it's sending and defaults to HTML.
>
> So, basically this is just an unfortunate mismatch.
>
> This is caused by OTR, because the OTR data is sent in plain text, and
> *that* is the message that Jitsi/Pidgin receives. I do not think there
> is a way to express what the *decrypted* message content type is. I had
> a quick look at this a few weeks ago and that was as far as I got
with this._______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
Ok then the answer is simple: Clients need to filter out everything what
is not plaintext in case they use OTR. It seems they break the standard
now. So content guessing is the wrong way, it needs to be fixed in the
OTR plugins etc.
It´s like putting a HTML formatted email into a text/plain MIME part.
This you also cannot/should not fix at the receiving side...
BR Florian
···
Am 18.02.2015 um 22:44 schrieb Danny van Heumen:
Well, it's like this. XMPP (I only know for the XMPP case) supports
adding some kind of content type to explain how the message should be
interpreted. However, since we transmit an OTR-encrypted message, the
content type is used to interpret the OTR-encrypted message content,
which is plain text.
Hi Florian,
Ok then the answer is simple: Clients need to filter out everything
what is not plaintext in case they use OTR. It seems they break the
standard now. So content guessing is the wrong way, it needs to be
fixed in the OTR plugins etc.
I'm glad you see it that way. Unfortunately that is not enough to
resolve this issue. I am glad, though, that you see what the nature of
this issue really is.
It´s like putting a HTML formatted email into a text/plain MIME part.
This you also cannot/should not fix at the receiving side...
Yep, that is exactly it.
Danny
···
On 18-02-15 23:19, Florian Leeber wrote:
BR Florian
Am 18.02.2015 um 22:44 schrieb Danny van Heumen:
> Well, it's like this. XMPP (I only know for the XMPP case) supports
> adding some kind of content type to explain how the message should be
> interpreted. However, since we transmit an OTR-encrypted message, the
> content type is used to interpret the OTR-encrypted message content,
> which is plain text._______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
Good Morning,
by the way, Jitsi will display formatted text correctly when OTR if off, but you cannot enter formatted text into Jitsi? It´s a little bit strange also.
Why all this is important for me: I am doing private studies about alternatives to Skype and how to reach parity with Skype. So I am focused on the user experience at the moment, because this is what people tend to notice first, and where they will tell me: "But Skype can do <xy>..." - you know the reasoning.
In order to reach parity with Skype, Jitsi shall be consistent in doing it´s things: If it can show formatting, it should also allow to enter it. If it can show it in plaintext, then also with OTR etc.
BR Florian
Zitat von Danny van Heumen <danny@dannyvanheumen.nl>:
···
Hi Florian,
On 18-02-15 23:19, Florian Leeber wrote:
Ok then the answer is simple: Clients need to filter out everything
what is not plaintext in case they use OTR. It seems they break the
standard now. So content guessing is the wrong way, it needs to be
fixed in the OTR plugins etc.I'm glad you see it that way. Unfortunately that is not enough to
resolve this issue. I am glad, though, that you see what the nature of
this issue really is.It´s like putting a HTML formatted email into a text/plain MIME part.
This you also cannot/should not fix at the receiving side...Yep, that is exactly it.
Hello,
I filed a bug in the Pidgin OTR plugin tracker, lets see what will
happen: https://bugs.otr.im/issues/78
BR Florian
···
Am 19.02.2015 um 21:22 schrieb Danny van Heumen:
I'm glad you see it that way. Unfortunately that is not enough to
resolve this issue. I am glad, though, that you see what the nature of
this issue really is.
I already opened a issue a while ago [1] and the answer was:
"HTML is explicitly mentioned in the OTR specification but optional.
This is thus, according to specification:
https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
But this of course causes problems for non-GUI clients."
Regards,
Klaus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Now I understand Danny´s comment about why it is not straightforward... 
Okay to me this sounds like someone wanted to make his/her life easier.
By specifying the standard like this, and effectively ignoring other
people´s issues with that you have an easy time, indeed.
It would be better to require a content header inside the OTR message,
and to help the clients with decoding the message. With that header set,
also other applications could use OTR, not only text messaging (maybe
OTR filetransfer?)
BR Florian
···
Am 20.02.2015 um 20:25 schrieb Klaus Herberth:
I already opened a issue a while ago [1] and the answer was:
"HTML is explicitly mentioned in the OTR specification but optional.
This is thus, according to specification:
https://otr.cypherpunks.ca/Protocol-v3-4.0.0.htmlBut this of course causes problems for non-GUI clients."