Bug 203058 - Non-ascii characters generate trash in address lists
Non-ascii characters generate trash in address lists
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: evolution-data-server (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
: i18n
Depends On:
Blocks: 208805
  Show dependency treegraph
 
Reported: 2006-08-18 00:09 EDT by Jong Bae KO
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: evolution-data-server-1.9.2-2.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-08 12:39:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
before add to TO (91.80 KB, image/png)
2006-08-18 00:09 EDT, Jong Bae KO
no flags Details
after click Add button (88.76 KB, image/png)
2006-08-18 00:10 EDT, Jong Bae KO
no flags Details
Patch for solving problem related to i18n text in contacts (2.07 KB, patch)
2006-09-25 11:32 EDT, Mayank Jain
no flags Details | Diff
Patch for list preview (5.93 KB, patch)
2006-10-03 07:36 EDT, Mayank Jain
no flags Details | Diff
patch for enabling display of i18n mail ID's in the addressbook (11.17 KB, patch)
2006-10-06 03:53 EDT, Mayank Jain
no flags Details | Diff
new patch as per guidelines - for evo (11.18 KB, patch)
2006-10-06 04:47 EDT, Mayank Jain
no flags Details | Diff
Updated patch (11.13 KB, patch)
2006-10-09 02:33 EDT, Mayank Jain
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 359806 None None None Never

  None (edit)
Description Jong Bae KO 2006-08-18 00:09:45 EDT
Description of problem:
I can see the korean in the contact text box.
but when I add korean into TO, it shows Wrong words.

Version-Release number of selected component (if applicable):
evolution-2.7.4-4
scim-1.4.4-29.fc6
scim-hangul-0.2.2-6.fc6

How reproducible:
allways

Steps to Reproduce:
1. Make New mail and Click TO button
2. make korean contact like 고종배<jko@redhat.com>
3. click Add button
  
Actual results:
?UTF-8?Q?=EA=B3=A...

Expected results:
고종배 or 고종배<jko@redhat.com>

Additional info:
Comment 1 Jong Bae KO 2006-08-18 00:09:45 EDT
Created attachment 134422 [details]
before add to TO
Comment 2 Jong Bae KO 2006-08-18 00:10:28 EDT
Created attachment 134423 [details]
after click Add button
Comment 3 Mayank Jain 2006-09-14 05:43:48 EDT
> Steps to Reproduce:
> 1. Make New mail and Click TO button
> 2. make korean contact like ê³ ì¢…ë°°<jko@redhat.com>
> 3. click Add button

Hi,

Is it reproducible with any korean input? I'm asking because I'm not able to add
your address as i dont have LDAP setup. Is there any other way to reproduce this
bug?

Thanks,
Mayank
Comment 4 Mayank Jain 2006-09-14 05:45:39 EDT
Can you please recheck this bug with evolution-2.8.0-1.fc6 or above versions &
report the findings?

Thanks,
Mayank
Comment 5 Mayank Jain 2006-09-14 06:04:07 EDT
Ok, verified, this bug is still there in evolution-2.8.0-1.fc6. Removing the
NEEDINFO flag. Re-assigning the bug to myself.
Comment 6 Mayank Jain 2006-09-14 06:05:43 EDT
Changing version to devel.
Comment 7 Jong Bae KO 2006-09-14 20:05:49 EDT
This bug is included CJK. I test with Korean, Chinese and Japanese on
evolution-2.8.0-1.fc6
Comment 8 Mayank Jain 2006-09-18 09:28:14 EDT
From initial investigation...

this is how the control moves
e-d-s -> add_destination (EDestinationStore *destination_store, EContact
*contact, gint email_n)
Comment 9 Mayank Jain 2006-09-19 01:25:17 EDT
Confirmed, this happens with indic contacts also.
Checked with a contact in hi_IN language.
Comment 10 Mayank Jain 2006-09-25 06:46:40 EDT
$e-d-s/libedataserverui/e-name-selector-dialog.c:transfer_button_clicked is used
to transfer contacts from source to destination
Comment 11 Mayank Jain 2006-09-25 07:29:07 EDT
$e-d-s/libedataserverui/e-name-selector-dialog.c:destination_column_formatter
might be one function to concentrate on.
Comment 12 Mayank Jain 2006-09-25 08:18:38 EDT
Exact reason of bug...

contact_column_formatter - does correct rendering because it generates the names
which are added to the GtkTreeView by using g_strdup_printf

destination_column_formatter - does NOT works because it generates the names
(which are added to destination GtkTreeView) bu using e_destination_get_address
function, which in turn uses camel_address_encode (or internet_encode) to mess
up the encoding of names.

Hence, IMHO this bug can be fixed from two viewpoints...

1) Either continue the method used in contact_column_formatter - ie, use
g_strdup_printf to create the addresses.
2) or modify Camel's internet_encode function to return with proper encoding &
hence a viable address which can be added to the destination box.

But since camel_address_encode looks like an overloaded function, i'd suggest
that following (1) would be a better option as just fixing internet_encode wont
help. All the overloader functions need to be fixed.

Besides, Camel is not in the scope of this bug.

**Changing component to evolution-data-server.
Comment 13 Mayank Jain 2006-09-25 08:27:55 EDT
The function that does the final blow... camel_header_encode_phrase
Comment 14 Mayank Jain 2006-09-25 11:32:11 EDT
Created attachment 137058 [details]
Patch for solving problem related to i18n text in contacts

I modelled destination_column_formatter on the basis of how
contact_column_formatter is implemented.
Comment 15 Mayank Jain 2006-09-25 11:34:04 EDT
Matthew, before actually building this patch into rawhide, can you please give
it a quick check... specially with actually sending an email on live internet.

Thanks,
Mayank
Comment 16 Mayank Jain 2006-09-25 11:35:38 EDT
Changed bug description to a more meaningfull heading.
Comment 17 Mayank Jain 2006-09-27 10:11:51 EDT
One straight forward way to solve this bug would have been to implement 

case EVC_ENCODING_QP:
			g_warning ("need to implement quoted printable decoding");
			break;

in function 
GList*
e_vcard_attribute_get_values_decoded (EVCardAttribute *attr)
Comment 18 Matthew Barnes 2006-09-27 13:32:29 EDT
Mayank, the patch produces this block of logic:

    if (e_destination_list_show_addresses (destination)) {
            const gchar *name;

            name      = e_destination_get_name (destination);

            string = g_strdup_printf ("%s", name ? name : "?");
    } else {
            string = g_strdup (e_destination_get_name (destination));
    }

Can this be simplified?  How important is the question mark when name is NULL?

Maybe something like:

    name = e_destination_get_name (destination);
    if (name == NULL && e_destination_list_show_addresses (destination))
            name = "?";
    string = g_strdup (name);
Comment 19 Mayank Jain 2006-09-28 03:56:18 EDT
Hi Matthew,

I just replicated the functionality of source_column_formatter (the function
above destination_column_formatter). 

I have no issues with either of them... but for the sake of consistancy, i'd
suggest that either both functions should be changed or both should be kept
same... or the different logic might confuse other developers.

Your pick Matthew... i'm just concerned with getting the bug fixed. :)
You are the maintainer... choose the best way :)

BTW... I think both code segments act seemingly in the same way. :) Nice finding!
Comment 20 Mayank Jain 2006-10-03 07:09:53 EDT
Matthew, this bug is related to different components.

The patch #14 is fro e-d-s
The next patch in #20 will be for evo
Then another one will be for evo.

Should we file new bugs for evo components?

As seen here... http://bugzilla.gnome.org/attachment.cgi?id=67834&action=view
The bug in "contact list selector" dialog box is from e-d-s
The bug in "List Preview" is for evo

Matthew... what say?
Comment 21 Mayank Jain 2006-10-03 07:36:13 EDT
Created attachment 137639 [details]
Patch for list preview

Patch as mentioned in #19, patch is for Evo
Comment 22 Mayank Jain 2006-10-03 07:52:28 EDT
> Patch as mentioned in #19, patch is for Evo

This line should be read as...

Patch as mentioned in #20, patch is for Evo
Comment 23 Mayank Jain 2006-10-06 03:53:44 EDT
Created attachment 137901 [details]
patch for enabling display of i18n mail ID's in the addressbook

This patch completely solves this bug.
Comment 24 Mayank Jain 2006-10-06 03:55:53 EDT
Over to you Matthew :)
Comment 25 Mayank Jain 2006-10-06 04:47:30 EDT
Created attachment 137905 [details]
new patch as per guidelines - for evo

patch for enabling display of i18n mail ID's in the addressbook
Comment 26 Mayank Jain 2006-10-09 02:33:14 EDT
Created attachment 138026 [details]
Updated patch
Comment 27 Matthew Barnes 2006-10-12 15:08:49 EDT
(In reply to comment #20)
> Should we file new bugs for evo components?

Yes, please move the Evolution patch to a new bug.  That way we can track it
easier for RHEL5.  Bug #208805 doesn't include the Evolution stuff.
Comment 28 Mayank Jain 2006-10-13 03:18:58 EDT
Bug 210606 - filed for evo.
Comment 29 Matthew Barnes 2006-10-13 07:57:22 EDT
Thanks Mayank.
Comment 30 Mayank Jain 2006-10-16 06:19:01 EDT
You are welcome Matthew :)
Comment 31 Matthew Barnes 2006-11-06 14:58:33 EST
Mayank,

While looking over your patch some more, I noticed that e-vcard.c in
evolution-data-server might be a more appropriate place for your quoted
printable string decoder.

There's even some placeholders in the code to guide you:

        case EVC_ENCODING_QP:
                g_warning ("need to implement quoted printable decoding");
                break;
Comment 32 Mayank Jain 2006-11-07 05:22:31 EST
Hi Matthew,

The patch in #14 solves this bug. I think this can be closed & that related to
evo can be continued in bug 210606.

Thanks,
Mayank
Comment 33 Matthew Barnes 2006-11-08 12:39:11 EST
Right, I posted comment #31 to the wrong bug.  Actually I just noticed that you
had the same observation in comment #17.  D'oh!

Fixed in evolution-data-server-1.9.2-2.fc7.
Comment 34 Mayank Jain 2006-11-09 03:19:50 EST
Thanks :)

Note You need to log in before you can comment on or make changes to this bug.