0

I made a package that caches stuff (robust-externalize) and my goal now is to compile automatically many images into a single document to save the loading time of the preamble during the first compilation. So I was planning to write in a file something like:

\documentclass[varwidth,margin=5mm]{standalone}
\usepackage{tikz}
\usepackage{amsmath}
\NewDocumentEnvironment{robExtNewPage}{}{}{}
\standaloneenv{robExtNewPage}
\begin{document}

\begin{robExtNewPage}
  \gdef\test{I should be removed after this page}
  \begin{minipage}{1.0\linewidth}
    \begin{align}
      1+1
    \end{align}

  \end{minipage}
\end{robExtNewPage}


\begin{robExtNewPage}
  This should give an error:
  \test


See, equations are also not correctly numbered (I want to reset the number):\


\fbox{\begin{minipage}{1.0\linewidth}
    \begin{align}
      1+3
    \end{align}

  \end{minipage}}
\end{robExtNewPage}


\end{document}

where each image is inside robExtNewPage. This should work more or less as expected, but I would like to enforce purity as much as possible, and in particular I do not want stuff from image 1 to leak to image 2, or I would get non-deterministic results. So is it possible to save the state at the end of \begin{document}, and restore it at the beginning of any robExtNewPage, so it is (more or less) impossible to signal between images? I guess that local variables are automatically reset, so I guess my question concerns rather the global variables/macros.

tobiasBora
  • 8,684
  • Not in general. If you know what the global things are, you can save and restore them, but you can't stop something rewriting your stored versions if it wants to and you can't save and restore everything without, well, saving and restoring everything (and even that would only work for things which can be saved and restored). TikZ, for example, goes to great lengths to contain the contents of pictures, precisely so they don't affect later pictures or later non-pictures. But, of course, somebody may make a change in such an environment global. – cfr Sep 19 '23 at 02:34
  • I mean, you can redefine \gdef inside the environment, but the reason to use \gdef is precisely to make the definition global, so doing so will result in unexpected behaviour (from the user's perspective). [I hope redefining \gdef is an obviously bad idea but, in case it isn't, it is a bad idea.] – cfr Sep 19 '23 at 02:37
  • 1
    well "purity" is not everything. One of the main problem of tikz externalize is that some images actually need data from the external state like references, citations or the state of counters. – Ulrike Fischer Sep 19 '23 at 07:44
  • @cfr thanks, to bad there is no "mega group" that also groups \gdef. Actually, I don't mind to change a bit the context (of course we need to save the saved state), but in a minimal way. Or is it maybe possible (outside of the latex code), to run an interactive pdflatex that save its internal state right after the preamble, and gets as input some stuff to typeset and typeset them with that same state at every request? I remember web-tikz to do something like that, but in a browser. – tobiasBora Sep 19 '23 at 10:02
  • @UlrikeFischer I my use cases, most pictures have no references or citations, but it is always possible to temporarily disable externalization in these cases (but I actually plan to eventually make it work for references as well by parsing the aux file). The macros that completely expand can be passed, for instance counters can be explicitly passed to the context of the picture using something like set placeholder eval={__thepage__}{\thepage}: in that case the picture will be rebuilt only of the current page changes. – tobiasBora Sep 19 '23 at 10:07
  • Maybe \globaldefs is relevant here, but be careful with that register. – Udi Fogiel Sep 19 '23 at 12:57
  • @UdiFogiel thanks, but seems like this would break anything that actually require a global definition… – tobiasBora Sep 19 '23 at 13:31
  • What's the use case exactly? Usually, people would like externalise to typeset a picture with the same result as typesetting it at the same point in the document without externalisation. And, if typesetting the picture at that point would affect later stuff, they want the externalised version to affect it in the same way. TikZ externalisation can't do that because it does a separate run to produce the picture. But if you're not doing a separate compilation, why would you want to block the picture's influence on later stuff or the effects on the picture of earlier stuff? – cfr Sep 19 '23 at 22:10
  • @cfr so I also externalize the picture to another file in normal case. I just want to offer another optimized compilation setting where I compile all images at once to save the loading time of the preamble for each picture… combined with parallelization (that is already possible) it might give nice improvements, for instance if I batch pictures by groups of 25 in the same file and run all these compilations in parallel. But I still want this optimized compilation to give the same result as the non-optimized compilation or it could produce annoying bugs and impurity issues. – tobiasBora Sep 19 '23 at 22:45
  • So you want a different result from just typesetting the image at that point in the document? OK, that makes sense. That's not how I've ever thought about externalisation, but that's probably just an assumption on my part. – cfr Sep 19 '23 at 22:50
  • @cfr well yes and no: I basically want purity over anything else (i.e. if the result is different, it MUST automatically recompile without manually cleaning the cache). So the picture should appear like it appears at the point of the document, BUT to ensure purity any dependency on external data/counters/… should be explicit, like "this picture uses this counter" (as I guess it is not possible to automatically detect it). Once I know that the picture uses the counter, I can pass the current value to the picture, and it works quite reliably in my experience for counters (see doc section 3.7). – tobiasBora Sep 19 '23 at 22:59
  • But that doesn't seem to require resetting everything. What if a picture contains, say, \refstepcounter for a counter used later in the document? I don't see what resetting the value of the counter gets you except a problem. That is, what problem are you trying to solve? What 'impurities' are you concerned about? – cfr Sep 19 '23 at 23:05
  • @cfr So if a cached picture wants to change a counter, then it needs to write to the file hashofpicture-out.tex (cf \writeRobExt{}) the latex code to change the value, with something like: \immediate\write\writeRobExt{\string\refstepcounter{somecounter}}: this file will be automatically loaded before including the pdf file (cf doc section 3.9). We use for instance this to know the depth of the picture to include it properly. – tobiasBora Sep 19 '23 at 23:32
  • Let us continue this discussion in chat. – tobiasBora Sep 19 '23 at 23:40

0 Answers0