Re: Re: Alternative mbstring implementation using ICU

Hi!

They calculate the total width of a string based on "east asian width" property, which is still valid to give a rough measurement of the rendered string.

OK, I guess if it's some kind of special calculation that doesn't follow from others it should be preserved, there are tons of such special functions in PHP.

That's a common problem, IIRC PHP 6 converters have configurable error modes for that. Don't unicode_set_error_handler() and unicode_set_error_mode() do what you want?

I guess it isn't what I want. If my understanding is correct, a handler set by unicode_set_error_handler() merely deals with the aftermath and cannot interact with the converter. There are good

That depends. For some error modes, it says to converter to replace invalid chars with some other char or skip it. You can't however now specify custom mappings (I'm not sure ICU allows that, but maybe it can be simulated...). Here the question is - is it really worth to keep whole separate conversion system for just this, or can it be done with standard conversion, possibly somewhat tweaked?

In addition to these, shouldn't there be any case where one have to manipulate Unicode strings on per-coded-character-basis rather than per-grapheme-basis just like substr() in PHP6?

In PHP 6 right now it's actually the only case, grapheme functions not even ported to PHP 6 yet (I know, not good) - but that's what regular str* functions should be doing, right? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com