Fix sending Ink (handwriting) messages to WLM 8.5 and 2009

[valerio]

Our Handwriting messages don't show up in WLM 8.5 and 2009, sometimes. If the contact has ISF support, is using WLM 8.5 or 2009, and we're in a 1-to-1 chat with that contact, simply sending gif inks won't work; they need to be sent over a P2P connection.

The fix would be either to get that p2p connection to work right, or to implement isf support. Since we were already planning to add isf support to 2.1, that will be our fix:

• Users without wlm 8.5 and 2009 weren't affected anyway
• Users without isf support weren't affected anyway
• All other users are able to show isf inks so the fix will work.

 Old topic reference

[fontknocker]

It looks like WLM uses a very specific GIF format. I tried sending a standard, no-frills 8-bit GIF image to WLM and it failed. aMSN can't do it either so I guess that rules out a bug in our image sending code.

Every gif-based ink message that comes from WLM seems to contain the same 1000-byte (or so) sequence at the beginning of the image. Without decoding this GIF header I'm not sure it's going to be possible to fix this before 2.0-final. It might be worth holding out until we get libisf working.

[sifcenter]

The format of the image sent is right but not the mode. In single chat the WLM accepts only ink sent by P2P messages, while in the group chat the ink must be sent by SB. KMess sends all by SB, so it works only in group chat.

[fontknocker]

ATM we can't send ink in a group chat either but that will most likely be because we're sending a PNG and not a GIF. We'll have to include either libgif or CxImage if we want it to work.

[fontknocker]

Turns out that WLM does accept PNG, so that means we need to somehow send inks via P2P is a 1-1 chat.

[sjors]

I just did this:

1 Dumped a session with wireshark (where the ink from kmess doesn't display) 2 Notice that the png from KMess is indeed not displayed, also notice that the gif from WLM is simply sent over switchboard 3 Saved the received gif data to a file 4 Hacked into KMess that on button click, that that gif file is sent instead of a normal ink 5 Retried the session and saw how the .gif ink was correctly displayed.

• This rules out the idea that it may be switchboard/p2p-related.
• This rules out the idea that png should be displayed in the same way as gif
• This makes way for trying out libgif as a solution for this problem.

I'm going to look at libgif right now. :)

[sjors]

For the record, that is:

1. Dumped a session with wireshark (where the ink from kmess doesn't display)
2. Notice that the png from KMess is indeed not displayed, also notice that the gif from WLM is simply sent over switchboard
3. Saved the received gif data to a file
4. Hacked into KMess that on button click, that that gif file is sent instead of a normal ink
5. Retried the session and saw how the .gif ink was correctly displayed.

[sjors]

Also, I forgot to add this:

test1.png: PNG image, 182 x 83, 8-bit/color RGBA, non-interlaced test2.gif: GIF image data, version 89a, 126 x 59

test1.png is the file KMess sent to WLM, test2.gif is the file WLM sent to KMess. :-)

[sjors]

Done. I should say the generated gif images show a few artifacts which should be fixed, but... the inks display! :) Committing in a minute.

[sjors]

Windows Live Messenger 2009 showing an ink from KMess

[sjors]

Fixed this and some more bugs with r4602. The artifacts no longer appear and inks work perfectly again.

[sjors]

Fixed sending to WLM 8.5 again with r4605. The problem wasn't that inks should be sent over P2P, the problem was simply the header order. F*** YOU MS! These things don't have order, read the damn RFC's and spawn yourself a brain! :/

[valerio]

I couldn't make sending gif inks to wlm8.5 via p2p in half a day of working, I'll post here what I have now.

Reopening btw, we can't send ink to the whole lot of people who will stick to 8.5 for as long as possible, because they don't like the 2009 version.

[sjors]

Deferring to KMess 2.1 for the *real* ink fix, namely isf support. Updated the summary with the current state of things.

[valerio]

This was done with the completion of the isf-qt library, available  here.