[libgadu-devel] Wiadomości przychodzące i zamiana HTML-a na czysty tekst

2011-05-11 Thread Bartosz Brachaczek
Witam,
Funkcja gg_session_handle_recv_msg_80() zakłada, że zawsze dostanie
wiadomość w czystym tekście, natomiast wiadomość w formacie HTML jest
opcjonalna. Jednak, jak widzę, w przypadku dostania wiadomości w
formacie HTML wiadomość w czystym tekście jest całkowicie ignorowana i
do pola message struktury gg_event_msg jest przypisywany wynik funkcji
gg_message_html_to_text() z argumentem zawierającym przesłaną nam
wiadomość HTML. I tutaj rodzi się problem, bo jeśli klient libgadu
postanowi przeczytać atrybuty formatowania zamiast wiadomości HTML
(tak robi Kadu), a wynik funkcji gg_message_html_to_text() będzie się
różnił od wiadomości oryginalnie przesłanej przez rozmówcę, to
wynikiem będzie błędne wyświetlenie sformatowanej wiadomości. Taka
sytuacja ma miejsce w przypadku rozmowy z Infobotem, który w
wiadomościach czystym tekstem znaki nowej linii koduje jako \r\n, a
nie jako \n, jak oryginalny klient. Trudno mi sobie wyobrazić, jak w
rozsądny sposób można by dostosować do takiego przypadku funkcję
gg_message_html_to_text(), więc moje pytanie brzmi, dlaczego właściwie
libgadu dokonuje konwersji HTML-a do czystego tekstu, zamiast wziąć
to, co wysłał rozmówca? Prosta łata, którą załączam, zdaje się
rozwiązywać problem i moje testowanie jej w rozmowie z klientem
libgadu (Kadu), oryginalnym klientem GG 10.5, botem Infobot oraz botem
Allegro nie wykazało żadnych problemów.

Pozdrawiam,
Bartosz
diff --git a/src/handlers.c b/src/handlers.c
index a843b4b..17e22f9 100644
--- a/src/handlers.c
+++ b/src/handlers.c
@@ -926,23 +926,7 @@ static int gg_session_handle_recv_msg_80(struct gg_session *sess, uint32_t type,
 		}
 	}
 
-	if (sess-encoding == GG_ENCODING_CP1250) {
-		e-event.msg.message = (unsigned char*) strdup(packet + offset_plain);
-	} else {
-		if (offset_plain  sizeof(struct gg_recv_msg80)) {
-			int len;
-
-			len = gg_message_html_to_text(NULL, packet + sizeof(struct gg_recv_msg80));
-			e-event.msg.message = malloc(len + 1);
-
-			if (e-event.msg.message == NULL)
-goto fail;
-
-			gg_message_html_to_text((char*) e-event.msg.message, packet + sizeof(struct gg_recv_msg80));
-		} else {
-			e-event.msg.message = (unsigned char*) gg_encoding_convert(packet + offset_plain, GG_ENCODING_CP1250, sess-encoding, -1, -1);
-		}
-	}
+	e-event.msg.message = (unsigned char*) gg_encoding_convert(packet + offset_plain, GG_ENCODING_CP1250, sess-encoding, -1, -1);
 
 	if (offset_plain  sizeof(struct gg_recv_msg80))
 		e-event.msg.xhtml_message = gg_encoding_convert(packet + sizeof(struct gg_recv_msg80), GG_ENCODING_UTF8, sess-encoding, -1, -1);
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel


Re: [libgadu-devel] Wiadomości przychodzące i zamiana HTML-a na czysty tekst

2011-05-11 Thread Jakub Zawadzki
On Wed, May 11, 2011 at 02:57:52PM +0200, Bartosz Brachaczek wrote:
 Łata, którą załączam, zdaje się
 rozwiązywać problem i moje testowanie jej w rozmowie z klientem
 libgadu (Kadu), oryginalnym klientem GG 10.5, botem Infobot oraz botem
 Allegro nie wykazało żadnych problemów.

Racja, skoro korzystamy z odebranych formatek (a nie przerabiamy ich z htmla),
to powinniśmy też korzystać z orygianlnej wiadomości.

Chyba, że lepszym rozwiązaniem byłoby właśnie konwertowanie, Wojtek?

Pozdr.
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel


Re: [libgadu-devel] Wiadomości przychodzące i zamiana HTML-a na czysty tekst

2011-05-11 Thread Wojtek Kaniewski
Dnia 2011-05-11, śro o godzinie 14:57 +0200, Bartosz Brachaczek pisze:
 (...) Trudno mi sobie wyobrazić, jak w
 rozsądny sposób można by dostosować do takiego przypadku funkcję
 gg_message_html_to_text(), więc moje pytanie brzmi, dlaczego właściwie
 libgadu dokonuje konwersji HTML-a do czystego tekstu, zamiast wziąć
 to, co wysłał rozmówca?

Dlatego, że w HTML-u jest unikod, w czystym tekście CP1250. Idea była
taka, żeby dowolny klient mógł się posługiwać unikodem bez konieczności
parsowania HTML-a, ustawiając jedynie odpowiednie kodowanie.

Jedyne wyjście to chyba parsowanie HTML-a na tyle, na ile jest to
potrzebne do zapewnienia zgodności ze starym parsowaniem, tj. b, u,
i, img i atrybut color w span. Myślicie, że wystarczy parsowanie
jedynie tych tagów, żeby tylko zapewnić zgodność z Gadu-Gadu 10 i samym
libgadu?

Pozdr,
Wojtek

___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel