GNOME Bugzilla – Bug 324604
Non-ascii characters generate trash in address lists
Last modified: 2013-09-13 00:58:21 UTC
From: irios <irios@proin.es> To: submit@bugs.gnome.org X-Mailer: bug-buddy 2.12.1 Subject: Non-ascii characters generate trash in address lists Distribution: Ubuntu 5.10 (breezy) Package: Evolution Severity: Normal Version: GNOME2.12.1 unspecified Gnome-Distributor: Ubuntu Synopsis: Non-ascii characters generate trash in address lists Bugzilla-Product: Evolution Bugzilla-Component: Contacts [was: Addressbook] Bugzilla-Version: unspecified Description: Description of Problem: Non-ascii characters in a name in the address book appear jumbled in certain fields. How it happens: I have names in my agenda with non-ascii chars, such as: Guillermo Fernández Gª-Rojo Magüi Miño I input them in the adress book, and everything looks fine. I write a new email for them. I click on the "Para" (TO, I guess) button and I get a window where I can select addressees. All my contacts appear (looking fine) in the left panel titled "Contactos". I click on Magüi Miño, and she is highlighted. I click on the "Añadir" ("Add", I guess) button beside the panel titled "Para". Junk appears on the panel titled "Para". It reads: "=?ISO-8859-1?Q?Mag=FCi_Mi=F1o?=<mminho@telefonica.net>" I click on "Cerrar" ("Close"), and go back to the email window. The "Para" field reads "Magüi Miño", which is OK. I send the email. She receives it. I want to add Magüi to my friends list. This list already featured "Andrés Pascual" and "Fernando García". I select the business card view; individual addresses look fine, but the list looks already jumbled. I add Magüi. More junk appears on the card view. I want to send a message to the list: I right-click on it and select "Send Message", and a new email window appears; the "To" field is full of junk. I send the message nonetheless; everybody gets it. I view the sent message in the "Sent" folder; It looks fine. ------- Bug created by bug-buddy at 2005-12-20 12:41 ------- Bugreport had an attachment. This cannot be imported to Bugzilla. Contact bugmaster@gnome.org if you are willing to write a patch for this.
also see bug 261457
marking bug 332665 as a duplicate of this one, adding the same dependency.
*** Bug 332665 has been marked as a duplicate of this bug. ***
see http://bugzilla.gnome.org/attachment.cgi?id=67834&action=view for a screenshot.
*** Bug 355365 has been marked as a duplicate of this bug. ***
*** Bug 355731 has been marked as a duplicate of this bug. ***
Downstream bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203058
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. Andre: please change the component to evolution-data-server. Also, can you please request a Camel developer to have a look at this. Thanks, Mayank
The function that does the final blow... camel_header_encode_phrase
Created attachment 73375 [details] [review] 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.
makuchaku, your patch fixes the wrong display in the "contact list selector" dialog and in the "press To:-button in composer" dialog. it does not fix the wrong display in the preview pane and in the address cards view (also see bug 261457 and especially http://bugzilla.gnome.org/attachment.cgi?id=67834&action=view ). anyway, it's much better than before, though not totally fixed. :-)
I agree Andre. I was working on the preview pane part. Can we please file a new bug for that & close this one with fixed "To:" button functionality? Or should we continue in the same bug for both? IMHO, the fix for preview pane would be in evo & for the "To" button was in e-d-s. What say Andre?
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)
Created attachment 73936 [details] [review] Patch for list preview Patch for solving list preview trash generation poblem - should go in evolution
Andre, since the patch in #10 was for e-d-s & the patch in #14 is for evo, shouldnt the bug be broken for e-d-s & evo? Thanks, Mayank
Bug bifurcated for e-d-s http://bugzilla.gnome.org/show_bug.cgi?id=359806 Patch in c#10 goes to bug 359806
Created attachment 74117 [details] [review] patch for enabling display of i18n mail ID's in the addressbook This patch goes ito evo.
Created attachment 74120 [details] [review] new patch as per guidelines - for evo patch for enabling display of i18n mail ID's in the addressbook
Created attachment 74329 [details] [review] Modified patch
*** Bug 261457 has been marked as a duplicate of this bug. ***
*** Bug 422553 has been marked as a duplicate of this bug. ***
Matthew, Can you look at Makuchaku's patch?
still an issue in 2.11 - the preview pane part is fixed, but not the selector part and the contacts list pane part.
The patch looks fine. It fails to apply to trunk. Makuchaku/Matthew can one of you give an updated patch?
*** Bug 458907 has been marked as a duplicate of this bug. ***
Matthew/Milan ?
I reworked it to be compilable with actual evo sources, but it doesn't work for other than UTF-8 encoding, so the example from comment #0 doesn't work. I can see it worked in the upper contacts list, but not in the bottom preview. I will try to rework it. Feel free to commit the i18n patch, srag.
*** Bug 493620 has been marked as a duplicate of this bug. ***
*** Bug 493651 has been marked as a duplicate of this bug. ***
Milan, the i18n patch fails to apply on SVN trunk. If you have a re-worked patch, please attach it to the bug. marking approved patch as obsolete since it fails to apply on SVN trunk - too many changes since the patch was made..
Created attachment 102826 [details] [review] updated Mayank's patch Here's an updated Mayank's patch, slightly modified. There is one thing, I guess we can omit parse_qp_email function in case we can call a camel functions from Address book. If we can, then it will be better to use such already existed function which also supports other types of encodings, not only the UTF-8. So please reconsider the usage of this patch.
Milan, we can call camel. But it will be like link the lib just for that one function. Again, it may not be efficient IMO. Here we can duplicate the functionality with a fixme. At later point, when we do need Camel for something core, we can fix everything. I haven't tested now Milan. Just test and commit.
Created attachment 102896 [details] [review] proposed evo patch for evolution; I did test it and I realized the patch isn't complete and after a little discussion on IRC that that will be better to call camel function to decode, to support as many locales as camel, without duplicating code (btw, the address book already links camel, so no change in configure.in (I didn't know that)). There is only one thing I'm not sure about, and that is my change in addressbook/gui/widgets/e-addressbook-table-adapter.c I saw similar approach in message-list.c, but I'm not sure if it will be working or not here. I mean, if it leaks or not after my change.
Oh addressbook links camel? I didnt knew it. It looks fine. But yes you are right. Your patch leaks memory at the place where you mentioned. Hmm, you could have a strings hash table or so where you can manipulate this and free it at the end. With the hastable you can also void repeated decoding. It would decode the viewed/visible entries for every repaint.
Created attachment 103148 [details] [review] proposed evo patch ][ for evolution; It's almost same as the previous patch, few little tinnies I found during some little tests and solved leaking issue mentioned above.
Milan, looks fine to me. Just test and commit to trunk asap, so that it can have a week of testing before 2.21.90
Committed to trunk. Committed revision 34863.
*** Bug 512010 has been marked as a duplicate of this bug. ***
*** Bug 520260 has been marked as a duplicate of this bug. ***