[XeTeX] disabling xetex's default classes

[Jonathan Kew]

On 8 Oct 2009, at 16:22, Michiel Kamermans wrote:

> Jonathan Kew wrote:
>> The code that sets these up is in unicode-letters.tex, which is  
>> read during the creation of the default xetex and xelatex formats.  
>> You can easily write a loop that simply resets the classes of all  
>> the characters to 0, and override the \XeTeXinterchartoks commands  
>> in that file with null versions if you wish.
>>
>> (That code really should be updated to use \newXeTeXintercharclass  
>> and symbolic names, anyway....)
> Ahh, that's going to be asking a bit too much from users I guess...  
> I'm updating my old fontwrap package, and making a new package  
> unicodecharclass in the process which assigns each unicode block its  
> own class number, counting down from class 240 (there's 167 blocks  
> in unicode at the moment, so that leaves 70 classes on the left, and  
> a handful on the right), but it might be that classes 0 through 3  
> could interfere. By default I have the package now set up blank  
> transition rules, so things should be just fine, but if there had  
> been a way to 'empty' classes 0 through 3 without editing files,  
> that would have made things safer =)

Well, if your package overwrites the classes of all the characters,  
then 0 through 3 will be empty! I'm not sure what else you need?

>
> I'm not sure how this will behave in conjunction with polyglossia,  
> since that uses a decent number of classes too, but it seems like  
> the number of languages that supports is much lower than the 70  
> classes left untouched by this package.
>
> Has there been a 'ruling' on the \newXeTeXintercharclass concept? I  
> read up on the posts for it from last May, but it looked like  
> there'd not been any concrete decisions on what to do with it, just  
> that it was a pretty good idea (which it is =).

It should be present in the xetex and xelatex formats (defined via the  
xetex.ini and xelatex.ini files that are used to build these). So I'd  
recommend you use this to allocate your classes, rather than a  
separate (and potentially conflicting) allocator.

(I guess you'd have to check for its existence if you want your  
package to work on older setups, and provide your own definition if  
it's missing.)

JK