+++ This bug was initially created as a clone of Bug #203058 +++ 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> 3. click Add button Actual results: ?UTF-8?Q?=EA=B3=A... Expected results: ê³ ì¢ë°° or ê³ ì¢ë°°<jko> Additional info: -- Additional comment from jko on 2006-08-18 00:09 EST -- Created an attachment (id=134422) before add to TO -- Additional comment from jko on 2006-08-18 00:10 EST -- Created an attachment (id=134423) after click Add button -- Additional comment from majain on 2006-09-14 05:43 EST -- > Steps to Reproduce: > 1. Make New mail and Click TO button > 2. make korean contact like ê³ ì¢ë°°<jko> > 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 -- Additional comment from majain on 2006-09-14 05:45 EST -- Can you please recheck this bug with evolution-2.8.0-1.fc6 or above versions & report the findings? Thanks, Mayank -- Additional comment from majain on 2006-09-14 06:04 EST -- Ok, verified, this bug is still there in evolution-2.8.0-1.fc6. Removing the NEEDINFO flag. Re-assigning the bug to myself. -- Additional comment from majain on 2006-09-14 06:05 EST -- Changing version to devel. -- Additional comment from jko on 2006-09-14 20:05 EST -- This bug is included CJK. I test with Korean, Chinese and Japanese on evolution-2.8.0-1.fc6 -- Additional comment from majain on 2006-09-18 09:28 EST -- From initial investigation... this is how the control moves e-d-s -> add_destination (EDestinationStore *destination_store, EContact *contact, gint email_n) -- Additional comment from majain on 2006-09-19 01:25 EST -- Confirmed, this happens with indic contacts also. Checked with a contact in hi_IN language. -- Additional comment from majain on 2006-09-25 06:46 EST -- $e-d-s/libedataserverui/e-name-selector-dialog.c:transfer_button_clicked is used to transfer contacts from source to destination -- Additional comment from majain on 2006-09-25 07:29 EST -- $e-d-s/libedataserverui/e-name-selector-dialog.c:destination_column_formatter might be one function to concentrate on. -- Additional comment from majain on 2006-09-25 08:18 EST -- 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. -- Additional comment from majain on 2006-09-25 08:27 EST -- The function that does the final blow... camel_header_encode_phrase -- Additional comment from majain on 2006-09-25 11:32 EST -- Created an attachment (id=137058) 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. -- Additional comment from majain on 2006-09-25 11:34 EST -- 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 -- Additional comment from majain on 2006-09-25 11:35 EST -- Changed bug description to a more meaningfull heading. -- Additional comment from majain on 2006-09-27 10:11 EST -- 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) -- Additional comment from mbarnes on 2006-09-27 13:32 EST -- 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); -- Additional comment from majain on 2006-09-28 03:56 EST -- 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! -- Additional comment from majain on 2006-10-03 07:09 EST -- 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? -- Additional comment from majain on 2006-10-03 07:36 EST -- Created an attachment (id=137639) Patch for list preview Patch as mentioned in #19, patch is for Evo -- Additional comment from majain on 2006-10-03 07:52 EST -- > Patch as mentioned in #19, patch is for Evo This line should be read as... Patch as mentioned in #20, patch is for Evo -- Additional comment from majain on 2006-10-06 03:53 EST -- Created an attachment (id=137901) patch for enabling display of i18n mail ID's in the addressbook This patch completely solves this bug. -- Additional comment from majain on 2006-10-06 03:55 EST -- Over to you Matthew :) -- Additional comment from majain on 2006-10-06 04:47 EST -- Created an attachment (id=137905) new patch as per guidelines - for evo patch for enabling display of i18n mail ID's in the addressbook -- Additional comment from majain on 2006-10-09 02:33 EST -- Created an attachment (id=138026) Updated patch -- Additional comment from mbarnes on 2006-10-12 15:08 EST -- (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.
-- Additional comment from majain on 2006-10-09 02:33 EST -- Created an attachment (id=138026) [edit] Updated patch The required patch.
Comment From Matthew Barnes (mbarnes) on 2006-11-06 14:58 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;
Hi Matthew, e_vcard_attribute_get_values_decoded in e-vcard.c cannot use my "parse_qp_email" function as my func first separates the QP string from the email address, strips it of new lines, etc... while the " case EVC_ENCODING_QP:" case expects just a QP parser/decoder. Though i thought of writing an eplugin (python) for this purpose as its just 5 lines of code in python to decrypt a QP address... but thats no sooner. Hence from my side, I'd just prefer to keep it this way. What do you say :) Thanks, Mayank
Hi Matthew, If the patch in Rawhide, can you please move this bug to MODIFIED? Thanks :)
Matthew, what's the status with this one?
Moving to F8Target
This looks ok to me in current evo in rawhide. Hu Zheng, could you please check too?
This bug should have already be fixed. F7 have no problem too.
Thanks. Look like the patch got merged upstream [1]. [1] http://bugzilla.gnome.org/show_bug.cgi?id=359806