Committed, thanks.

Patch: Add test for PCRE and PCRE utf-8 support in test.php

I'm in favor of a test.php addition with this strategy.

BTW, this check:

preg_match_all("/(.{1})/su", $var, $m);

was added precisely because the old code (using String functions) did 
not work in several cases.  So a fallback function is most likely out 
of the question.

It returns (int)0 if it doesn't match and (boolean)false if there's an error.

Also we could use a pattern that always matches like this:



echo "Result: ".preg_match("/.*/u", "test")."\n";



I just disabled utf-8 support again to test it. On the command line I 
have even seen an error message:

"Warning: preg_match(): Compilation failed: this version of PCRE is 
not compiled with PCRE_UTF8 support at offset 0."

But it also returns false if it doesn't match, which is the whole 
purpose of preg_match().

preg_match_all returns FALSE if you specify the "u" pattern modifier 
to enable utf-8 mode.

But how can you test this?

Correct, JSON data must be UTF-8 encoded.

We could also assume PCRE with utf-8 support is standard by now and we 
should add a test to test.php to display a warning if it's not 
compiled in.

ISO-8559-1.



Horde_Serialize::serialize(SERIALIZE_JSON) converts the input to UTF-8 anway.

I was using a PCRE version without utf-8 support and so the following 
function call failed:



preg_match_all("/(.{1})/su", $var, $m);



This function is used to split a string into utf-8 characters. I've 
got it working now but maybe we need some kind of fallback code here.

Which charset is your interface using?

As far as I have traced it yet, the folder name get's lost in 
Horde_Serialize::serialize(JSON). I'm currently debugging it.

Are you sure this isn't a CSS issue?  This same issue crops up time to 
time in DIMP and it always turns out to be an issue with overflow or 
something similar.

Thanks for reproducing, Jan.

Gunnar can't reproduce it either.



If I switch the Horde_Tree renderer from javascript to HTML, the 
problem is gone.

Maybe it's a charset issue, I use quite an old glibc. I'll try to investigate.



Thomas

Not me.

Can anyone else reproduce this?

I see this bug again with horde cvs-HEAD and imp cvs-HEAD. The folder 
name is not displayed at all, but the icon is still clickable. Tested 
with Konqueror 3.5.6 and Firefox 1.5.

Should be fixed in CVS now. Will be in Horde 3.0.2.

Both have ISO-8859-1 and refresh do not change anything.

What charset do the "normal" pages have, what charset does the menu 
have, and does it change after the menu refreshed?

Found the Problem:



The label of  the Node with the umlaut was encoded with:

xxx\0äyyy  .... for an "ä"

xxx\0öyyy ... for an "ö" ... and so on, so the umlaut got a prefix 
"\0" (don't know why)



I added to templates/javascript/tree.js on line 319



var re = new RegExp ('\0', 'gi') ;

var label = label.replace(re, '') ;



before:

return '<a' + urlClass + ' href="' + this.nodes[nodeId]['url'] + '"' + 
target + onclick + '>' + label + '</a>';



Dirty hack, but it works .... would be good to find out, why this "\0" 
thing happens.

No, I think bug 809 is something else.



I found something interesting:

if i create a imap folder in IMP with an umlaut, it is displayed 
correctly in the sidebar and the umlaut "ä" (ae) is encoded in "g&5A-"



if i create the folder in Thunderbird or Outlook, the error occures 
and the "ä" is encoded with "&AOQ-" (seems that IE do not like this 
encoding)

Might be a duplicate of bug 809. Please confirm, and if so, find some 
common points of both your  systems.

The tree in the sidebar ends at the point,  where an umlaut (like 
ä,ö,ü) in a foldername (eg. imp -> imap foldername) appears.  This 
problem appears only in IE (v. 6), Firefox 1.0 and Opera 7 show the 
correct tree.



Screenshot IE:

http://www.flobauer.net/screenshot_ie.jpg



Screenshot Firefox:

http://www.flobauer.net/screenshot_firefox.jpg