12

I have the following MWE that used to work fine under TeXLive 14, 15 and 16, but fails on TeXLive 2017.

\documentclass{article}

\usepackage{tikz}
\usepackage{fontspec}
\setmainfont{Times New Roman}
\usepackage{mtpro2}

\begin{document} This is a problem. \end{document}

MTProII is the (freely available) package for Math Times Prof. II from PCTeX.

The example is an absolute MWE, changing anything on it (even the order) allows the file to execute fine. With the code as-above it fails with:

! No room for a new \count .
\ch@ck #1#2#3->\ifnum \count 1#1<#2\else \errmessage {No room for a new #3}
                                                                       \fi 
l.129 \alloc@0\count\countdef\insc@unt\pointcount@

I have looked at the some answers from Enrico Gregorio and David Carlisle on similar issues with another packages and the possibilities they bring on - do not apply here.

Any idea what's causing this, and how I can get around it?

10
  • 1
    That's due to some changes in the allocation code and mtpro2 didn't catch up (I reported it to pctex some month ago). Loading mtpro2 earlier should work (but I can't test now). – Ulrike Fischer Jun 11 '17 at 6:10
  • 3
    I don't have the report here, but if you can't load earlier, before the registers are used up and the extented allocation steps in, you could try \RequirePackage{etex} early enough (e.g. before\documentclass). The whole question was discussed here: chat.stackexchange.com/transcript/41?m=35904143#35904143 – Ulrike Fischer Jun 11 '17 at 11:37
  • 3
    I fixed this problem by replacing the line \alloc@0\count\countdef\insc@unt\pointcount@ with \newcount\pointcount@ in the mtpro2.sty file following the discussion in the link provided by Ulrike Ficher. – Marcos Oct 3 '17 at 17:51
  • 1
    I don’t particularly enjoy the idea of changing mtpro2.sty by oneself, since this issue should be reported to the package maintainer(s). So I am strongly in favor of the alternative by @UlrikeFischer: Add \usepackage{etex} before loading mtpro2 to increase the upper limit of the number of \count. See this answer by @DavidCarlisle. – Ruixi Zhang Aug 21 '18 at 17:52
  • 1
    @RuixiZhang A much better solution would be if more people would urge the package maintainer to correct the problem. I absolutly don't enjoy to have to load an outdated package (etex, which as David wrote should normally not be used) to get around wrong code in a package. – Ulrike Fischer Aug 21 '18 at 18:46
10

For very mysterious reasons, instead of doing

\newcount\pointcount@

the mtpro2.sty package (ab)uses the internal allocation mechanism. Alas, the internal allocation mechanism changed in the course of time but, of course, \newcount has continued to work as before.

There is no justification whatsoever for having a declaration such as

\alloc@0\count\countdef\insc@unt\pointcount@

except, possibly, for the desire to create problems to users.

The problem arises with the packages in that order because fontspec and tikz already exhausts the supply of counters with index below 255. Of course, using the old allocation mechanism will fail because the value of \count10, which holds the last allocated counter register, is 278 at the time the \alloc@ declaration in mtpro2.sty is encountered.

How to solve the problem? There are two ways. The easiest one is to edit mtpro2 changing line 138 to \newcount\pointcount@.

The second one is to exploit the fact that this call to \alloc@ is the only one in the package and to redefine it to do the right thing.

\documentclass{article}

\usepackage{fontspec}
\usepackage{tikz}

\makeatletter
\let\alloc@latex\alloc@
\def\alloc@#1#2#3#4{\newcount}% the current \newcount doesn't use \alloc@
\makeatother

\usepackage{mtpro2}

\makeatletter
\let\alloc@\alloc@latex
\makeatother

\setmainfont{Times New Roman}

\begin{document}

This is no more a problem.

\end{document}

I tried both and they work.

2
  • The are a couple of problems. First {mtpro} does not seem to have an active maintainer. It has not been touched in more than 15 years and probably will no be maintained in the future. The other is loading it early generates a LOT problems with interactions with other packages. The manual say -- load it last. – Paulo Ney Mar 30 '20 at 17:58
  • @PauloNey I had a new idea and it should work with no problem. – egreg Mar 30 '20 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.