[tex-live] About \newXeTeXintercharclass and latexrelease package

[Zdenek Wagner]

Hi all,

after seeing reports on \newXeTeXintercharclass I reprocessed my document
that makes use of both xevlna and ucharclasses packages. Both packages make
use of this primitive and the document was compiled without any error. I
have not checked all line breaks but it seems that 2015 gives the same
output as 2014.

Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz

2015-05-09 0:10 GMT+02:00 Qing Lee <sobenlee at gmail.com>:

> Hello,
>
> After running the following example,
>
>     % !TeX program  = XeLaTeX
>     \RequirePackage[2014/01/01]{latexrelease}
>     \newXeTeXintercharclass\foo
>     \stop
>
> an error occurred:
>
>     ! Undefined control sequence.
>     \newXeTeXintercharclass ->\e at alloc
>                                        \XeTeXcharclass \chardef
> \xe at alloc@interc...
>     l.3 \newXeTeXintercharclass
>                                \foo
>     ?
>
> It seems that \newXeTeXintercharclass is always defined in LaTeX
> 2015/01/01,
> while \e at alloc is not defined correspondingly.
>
> I can copy some codes from xetex.ini to fix this issue,
>
>     \makeatletter
>
>     \IncludeInRelease{0000/00/00}{\newXeTeXintercharclass}{Extended
> Allocation}
>     %
>     % Allocator for \XeTeXcharclass values, from Enrico Gregorio
>     %
>     \newcount\xe at alloc@intercharclass % allocates intercharclass
>     \xe at alloc@intercharclass=\thr@@ % from 4 (1,2 and 3 are used by CJK,
> AFAIK)
>     \def\xe at alloc@#1#2#3#4#5{\global\advance#1\@ne
>      \xe at ch@ck#1#4#2% make sure there's still room
>      \allocationnumber#1%
>      \global#3#5\allocationnumber
>      \wlog{\string#5=\string#2\the\allocationnumber}}
>     \def\xe at ch@ck#1#2#3{%
>      \ifnum#1<#2\else
>       \errmessage{No room for a new #3}%
>      \fi}
>     \def\newXeTeXintercharclass{%
>      \xe at alloc@\xe at alloc@intercharclass\XeTeXcharclass\chardef\@cclv}
> %at most 254
>     \EndIncludeInRelease
>
>     \makeatother
>
> But I don't think this is a good workaround.
>
> Best,
> Qing Lee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-live/attachments/20150509/f158e3ee/attachment-0001.html>