Symphony.

Hello.

Not a biggie, but i’ve noticed, that, when trimming occurs on a unicode letter, it somehow gets corrupted. Observed this since 2.0.8 RC1 - don’t know, if older versions had this.

Screen attached. Last letter must have been ‘i’ with a lengthening dash.

This is only visual - data itself remains intact, but it gets ugly as such lists grow up.

Not a browser issue (tested) and not a server issue (it also happens on deployment servers - linux/apache). Localhost in a screenshot is Wamp 2.0 on Win7.

Attachments:

sym_unicode.jpg

I have a feeling this is because Symphony uses standard string functions whereas multibyte string operations should ideally use the mbstring functions (http://php.net/manual/en/book.mbstring.php). The problem I think is that PHP needs to be specially compiled with mbstring functions (which aren’t included by default) so it can’t be relied on as standard.

http://getsymphony.com/discuss/thread/29858/#position-19

Agreed. We have been talking about mbstring functions more than once, and it seems that you can not rely on them being available. And so, to be honest, I don’t see any solution to this problem (which has always been there, and it probably is annoying in most languages, as it is in German).

While it may not be relied upon all the time, I think it’d be worth using function_exists so that if mbstring functions are available, we can provide the best experience to the user, and if not, fallback to our current, not so bulletproof implementation.

I came up with another solution the other day, where mbstring wasn’t available to me. Instead of trying to trim properly, I allow the incorrect trim to occur (thereby creating a broken character at the end of the string) but then remove any non UTF-8 characters from the string at the end thereby removing anything broken:

$string = preg_replace('/[^(x20-x7F)]*/','', $string);

Could that be a quick fix?