13

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?

Paulo Ney
  • 2,405
  • 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 06:10
  • @UlrikeFischer, I would be extremely interested in more details. In this MWE changing the order does allow it to process, but in my more complex working file changing the order did nothing. May be your report to PCTeX? – Paulo Ney Jun 11 '17 at 11:11
  • 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: https://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 03 '17 at 17:51
  • I am not sure I understand the reasoning here. Since when the existence of a solution has anything to do with being off-gopic??? – Paulo Ney Jun 04 '18 at 22:19
  • 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
  • 1
    Update: The problem still exists on Feb 2020. Fix by Marcos still works. – rhody Feb 12 '20 at 20:17
  • 1
    I've voted to reopen this question, since I don't see how 'being solved in a comment' classes a question as off-topic. The question is a significant one, since it clearly reports an incompatibility between a well-known package (mtpro2) and the current version of pdflatex+etex. The answer is ugly but clear – namely, ‘hack a local copy of mtpro2.sty – but I don't think that can be provided, by anyone, while the question is closed. It's important the answer is out there somewhere: I ran into this problem today, and though I'm reasonably sophisticated with LaTeX I'd never have fixed it myself. – Norman Gray Mar 29 '20 at 16:15
  • ...and (afterthought) I can't edit the question to make it clearer, since I don't think the question is the least bit unclear or off-topic. – Norman Gray Mar 29 '20 at 16:17

1 Answers1

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.

egreg
  • 1,121,712
  • 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