mdumic/cufon — comment on commit 82c82828af2527b62f0fc803b96b8791dbbed5c9
File:  line 0
By sorccu:

Hi,

1. For consistency I would only use one tab this time. Consistency makes the source easier to edit by other people as well.
2. I like it, but the availability of the function may be an issue since the renderers only share the global context. We may have to create api.preprocessText within the Cufon core if we want to avoid further refactoring. One solution would be to simply wrap everything inside an anonymous function and place the function there, however I would not accept it because I don't want to anything to be out of place.

Haven't really thought about the split vs charAt issue. I suppose the original reason was that it was easier to work with. I would imagine that it's slower because of the additional function calls, though. [Is that what you had in mind](http://jsperf.com/string-split-vs-charat)? Seems to be about 17% slower in my Chrome.
3. Good, but I may just have had a slightly better idea. First of all, let's rename the option to "ligatures". Then, let's make the default value of that option the object which latinLigatures currently holds, and get rid of latinLigatures altogether. This will allow people to add their own ligatures should the default ligature list prove insufficient. To disable ligatures, one would set the ligatures option to null. This does mean that the ligature regexp would have to be recreated each time a new Cufon.replace call is made, but it may be cacheable the same way for example textShadow and other options are (in Cufon.replace, although the caching is starting to take up quite a bit of space there...). So yeah, it's slower but I much prefer the idea of flexibility.

Thoughts?