<div dir="ltr"><div><div><div><div><div><div><div><div><div>Thanks for the test sources,<br><br></div>It all seems to work for me (texlive 2015/cygwin 64 build), but..<br><br></div>I do wonder if this change is going in the right direction.<br><br></div>The main problem with the char classes is not the overall number, in fact since the important thing as far as specifying code is the boundary between different classes rather than the classes themselves, there are now around 300 million such boundaries that could be specified, which seems more than enough!<br><br></div>The main problem is that each character can only be in one class which means that it is very hard to use these for any generic code. If you have already classified characters by (say) line breaking properties and then another package wants to classify by unicode block, or by default writing direction, then the only way to handle that is to enumerate all the intersecting properties and assign a a unique character class to each intersection, this leads to a combinatorial explosion in the number of<br></div>boundary tokens that need to be specified. Where you may have had a single specification for the boundary between LTR and RTL if you also want to classify each unicode block you need  separate classes for LTR and RTL characters in each block and then need to specify the same boundary tokens for all the possible changes of LTR in one block followed by RTL in another.<br><br></div>That limitation of course has always been there, but increasing the number of classes available highlights it more strongly.<br><br></div>Would it be impossibly difficult to extend the concept so that a character takes a list of character classes so that you can classify characters in more than one way without needing impossibly many character classes to do that?<br><br></div>Sorry for sounding ungrateful for the extension:-)<br><br></div>David<br><br><div><div><div><div><div><div><br></div></div></div></div></div></div></div>