Bug 57129 - Large fontsize and wrong special chars in messagewindow
Summary: Large fontsize and wrong special chars in messagewindow
Status: RESOLVED FIXED
Alias: None
Product: kopete
Classification: Applications
Component: IRC Plugin (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Kopete Developers
URL:
Keywords:
: 68853 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-04-11 15:07 UTC by Tais P. Hansen
Modified: 2003-12-18 15:27 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tais P. Hansen 2003-04-11 15:07:38 UTC
Version:           CVS (200304111340 CEST) (using KDE KDE 3.1.1)
Installed from:    Compiled From Sources
Compiler:          gcc version 3.2.2  
OS:          Linux

- Fontsize in message windows (Chat window style) are about 2 points bigger than configured with Base font in Chat Appearance. (Tested with IRC)

- Special characters such as '
Comment 1 Olivier Goffart 2003-04-11 16:26:40 UTC
Subject: Re: [Kopete-devel]  New: Large fontsize and wrong special chars in messagewindow

> - Special characters such as '
Comment 2 Tais P. Hansen 2003-04-14 15:05:08 UTC
Seems like random unicode support. :) - Some messages are parsed as 
unicode while others are not. 
 
The fontsize problem might be a DPI issue. Screen DPI not being taken into 
account when sizing the font? Printing KSpread sheets also produces much 
larger fonts than shown on screen. 
 
Comment 3 Casey Allen Shobe 2003-10-08 09:24:54 UTC
I can confirm this.  It seems that if the remote party sends latin-1, Kopete/
IRC shows it fine.  If the remote party sends unicode (xchat, ksirc), it does 
not show up correctly, looking like any application that does not implement 
unicode. 
Comment 4 Jason Keirstead 2003-10-19 16:47:14 UTC
Do you mean the other party is sending unicode type messages in xchat? Like with special caracters? Because messages from XChat appear fine to me.

Comment 5 Casey Allen Shobe 2003-10-19 20:41:20 UTC
> Do you mean the other party is sending unicode type messages in xchat? Like
> with special caracters? Because messages from XChat appear fine to me.

Fire up KSIRC and Kopete - join the same IRC channel.

With KSIRC, type 'g
Comment 6 Jason Keirstead 2003-10-27 03:14:48 UTC
This is partially resolved in CVS.

As long as the conversation is using UTF-8 everything will be a-ok.

Best we can do until I can add a per-conversation text codec selector, but that will have to wait until after 3.2 or in the make_it_cool branch
Comment 7 Jason Keirstead 2003-11-05 03:03:54 UTC
Resolved in make_it_cool IRC branch. (Post 3.2 fixes)
Comment 8 Jason Keirstead 2003-12-02 05:43:53 UTC
*** Bug 67727 has been marked as a duplicate of this bug. ***
Comment 9 Jason Keirstead 2003-12-02 05:44:59 UTC
*** Bug 68853 has been marked as a duplicate of this bug. ***
Comment 10 Piotr Szymański 2003-12-18 14:23:57 UTC
The fix proposed in make_it_cool branch is unacceptable for a nonlatin1 user. On irc one has no influence on the charset that the users are using. Even if i set it to iso8859-2 i still wont see a message with cp-1250 chars in it and some user might write them. The fact that those messages wont be displayed is a sever bug, what if sth. important was in them? 
The fact that some irc messages wont be displayed kinda disqualifies kopete as an irc client for nonlatin users...
Maybe reopen?
Comment 11 Jason Keirstead 2003-12-18 15:27:37 UTC
The code in make_it_cool is not a prooposed fix, it is *the* only way to support multiple charsets in IRC. There is no charset sent with the message, the channel, or the server, with the IRC protocol. The user has to set it in their client. It's not a "server bug", it's simply not a part of the IRC protocol at all.

This is the way *all* IRC clients behave, period. With some clients, you *can* read the text even if it isn't in your chosen codec, because by luck it is readable in your set codec. However, this is never guarneteed to work in any client, and in fact, does usually fail.

Unless you submit a new RFC to the IETF and get it accepted and implimented across the major networks, this behaviour isn't going to change.