On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson <magnu213@umn.edu> wrote:
It looks like the solution is to issue the following metapost command: warningcheck := 0;
Indeed. The new limit will be 32768 and could not be increased further in Metapost itself. The solution would be modification of how therion manages metapost pictures (currently they are stored in files data.1 to data.4000, with files data.4001 to data.4095 reserved for pattern definitions). This numbering scheme could be modified to allow more file name prefixes and consequently theoretically unlimited number of scraps processed by metapost. On the other hand there is still pdfTeX limit which would not allow much more scraps. PdfTeX uses internal registers for scraps referencing (scrap data is included only once in pdf file and can be referenced on multiple pages). You could avoid pdftex limit by using SVG output (if SVG viewers would process large number of internal references). In the longer-term future (a few years) I would like to use metapost as a library instead of external metapost executable, which would solve the problems with temporary files (and other problems as well).
However adding it in a code metapost warningcheck := 0; endcode block seems to have no effect, mpost still fails on more then 4096 scraps.
Therion currently inserts warningcheck:=1; before scraps without good reason, so it will be fixed soon. If the new warningcheck setting would work for you, I would prefer not to modify current file numbering scheme for metapost pictures and have it fixed later with implementation of metapost library. Martin