Le 21/05/2010 15:02, Khaled Hosny a écrit : > On Fri, May 21, 2010 at 02:53:30PM +0200, Manuel Pégourié-Gonnard wrote: >> IMHO, it shouldn't expect that. I tend to call that broken, unless someone >> provides me with a good explanation. > > There are some comments in the code, but basically Hans doesn't allocate > attributes at TeX end, and in lua he reserves ranges for special uses. > The code has a function, attributes.private, that allocates attributes > in this range, but we override it sense it doesn't check if the > attribute is already allocated, our replacement hand allocate attributes > using \newluatexattribute. > Ok, thanks for the explanation.
>>> The problem didn't show before switch to luatexbase, so I expect there >>> was some change in how \newluatexattribute allocates new attributes. >> >> There was a minor change, I don't remember the details right now, but indeed >> allocation didn't start at 0 previously for some reason. Since allocation >> should >> be a black box, I didn't expect the change to be noticeable, that's why I >> didn't >> announce it. > > I can work around it by allocating a dummy attribute first if you don't > want to change it back, not a big deal. > If allocating a single dummy attribute can solve the problem, I think is it the way to go. >> No. I can't see any nice way to to that. Well, if less than 127 attributes >> have >> been allocated, you could allocate dummy attributes up to 127, then start >> allocating your attributes. If more than 255 attributes have already been >> allocated, there's nothing you can do. > > OK, I wanted to be on the safe side, but lets just assume there no other > problems beyond the one we just found. > Code assuming attributes don't start at 0 is probably fairly rare (all other allocation starts at 0), so I think (hope) it'll be ok this way. Thanks, Manuel.
