Bug 210606

Summary: Non-ascii characters generate trash in address lists & address list preview
Product: [Fedora] Fedora Reporter: Mayank Jain <majain>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: high    
Version: rawhideCC: eng-i18n-bugs, majain, smaitra, zhu
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Fedora 7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-11 07:37:19 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 210834, 235704    

Description Mayank Jain 2006-10-13 03:16:11 EDT
+++ 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@redhat.com>
3. click Add button
  
Actual results:
?UTF-8?Q?=EA=B3=A...

Expected results:
ê³ ì¢…ë°° or ê³ ì¢…ë°°<jko@redhat.com>

Additional info:

-- Additional comment from jko@redhat.com on 2006-08-18 00:09 EST --
Created an attachment (id=134422)
before add to TO


-- Additional comment from jko@redhat.com on 2006-08-18 00:10 EST --
Created an attachment (id=134423)
after click Add button


-- Additional comment from majain@redhat.com on 2006-09-14 05:43 EST --
> 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

-- Additional comment from majain@redhat.com 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@redhat.com 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@redhat.com on 2006-09-14 06:05 EST --
Changing version to devel.

-- Additional comment from jko@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2006-09-25 08:27 EST --
The function that does the final blow... camel_header_encode_phrase

-- Additional comment from majain@redhat.com 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@redhat.com 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@redhat.com on 2006-09-25 11:35 EST --
Changed bug description to a more meaningfull heading.

-- Additional comment from majain@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2006-10-06 03:55 EST --
Over to you Matthew :)

-- Additional comment from majain@redhat.com 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@redhat.com on 2006-10-09 02:33 EST --
Created an attachment (id=138026)
Updated patch


-- Additional comment from mbarnes@redhat.com 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.
Comment 1 Mayank Jain 2006-10-13 03:17:52 EDT
-- Additional comment from majain@redhat.com on 2006-10-09 02:33 EST --
Created an attachment (id=138026) [edit]
Updated patch


The required patch.
Comment 2 Mayank Jain 2006-11-07 05:21:34 EST
Comment From Matthew Barnes (mbarnes@redhat.com)  	 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;

Comment 3 Mayank Jain 2006-11-07 06:08:58 EST
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
Comment 4 Mayank Jain 2007-02-23 05:01:00 EST
Hi Matthew,

If the patch in Rawhide, can you please move this bug to MODIFIED?

Thanks :)
Comment 5 Christopher Aillon 2007-04-17 15:35:43 EDT
Matthew, what's the status with this one?
Comment 6 Matthew Barnes 2007-10-04 12:26:30 EDT
Moving to F8Target
Comment 7 Jens Petersen 2007-10-11 02:35:42 EDT
This looks ok to me in current evo in rawhide.

Hu Zheng, could you please check too?
Comment 8 Hu Zheng 2007-10-11 03:38:37 EDT
This bug should have already be fixed. F7 have no problem too.
Comment 9 Matthew Barnes 2007-10-11 07:37:19 EDT
Thanks.  Look like the patch got merged upstream [1].

[1] http://bugzilla.gnome.org/show_bug.cgi?id=359806