15

ArXiv expects you to upload sources. But - every once in a while - they upgrade their own TeX distribution (e.g. from TL 2011 to TL 2016, last year). This can affect how your document is rendered, and even theoretically break the build.

So, are we supposed to mind our ArXiv-submitted versions every few months and update as necessary? If not, how can this be avoided?

CarLaTeX
  • 62,716
einpoklum
  • 12,311
  • 3
    use bare minimals in your arxiv submissions so if a problem arises, thousands others will suffer too and someone else will solve the issue for you. They do keep some cached pdf/ps for a while, and for often downloaded papers I think. If nobody downloads your contributions, it is not so dramatic if TeX build fails someday. Said tongue in cheek of course! ;-) –  Apr 24 '18 at 13:35
  • 5
    https://arxiv.org/help/faq/texlive.html states "Our goal is to provide a stable TeX processing system where we are able to reprocess papers from TeX source at any point in the future. arXiv maintains all past TeX trees such that existing papers are processed using the TeX tree in effect when the paper was originally submitted. This preserves the original presentation (look-and-feel) of the paper." So there should be no problem with submissions that came out OK at the time they were uploaded. – moewe Apr 24 '18 at 14:10
  • 1
    I guess this is the first time I do not fully agree with @jfbu. I've encountered a number of older arXiv papers that could no longer be compiled. It might very well be that these have been repaired by now, but when I would have needed the pdf file it was unavailable. I know of people who used to add all the style files to the arXiv submission, but since 2005 or so this is no longer tolerated. So I guess what I want to say is that (a) there is not much you can do to make the submission "safe" and (b) you yourself may have to communicate with the arXiv if that happens. –  Apr 24 '18 at 14:23
  • 1
    The trick is to work in a cutting-edge area of science. That way, someone will disprove your results, long before your paper becomes unreadable. I feel sorry for the mathematicians, who expect that their results will be timeless. Or, switch to one of those "Studies" areas in social sciences, where nobody will understand what you're talking about in any case, so there's no loss. –  Apr 24 '18 at 14:43
  • I guess the only way to make your submission future-proof is to cut the flamboyant extras and rely on the standard features of LaTeX. Use as little additional packages as possible, avoid low-level features and hacks prefer high-level features instead. Many packages are really stable, but others are actively developed. If development is to move forward it can not always be guaranteed that everything will continue to work as before, some things need to be broken to move on. If there are breaking changes they are more likely to affect lower-level features than the high-level ones. ... – moewe Apr 24 '18 at 15:07
  • @jfbu: No, I won't use bare minimals... I use dozens of packages, and I don't intend to give them up :-( – einpoklum Apr 24 '18 at 15:09
  • @moewe: Can you make your first comment into an answer/ – einpoklum Apr 24 '18 at 15:09
  • ... Take biblatex as an example. That package is quite actively maintained and relatively young (first release in 2006, official stable release v1.0 in 2010) and has undergone its fair share of incompatible changes. The most prominent of those (v3.3) broke contributed and user-defined styles if they used low-level commands, higher-level features continued to work with a deprecation warning. If you only ever used the standard styles and only modified the output via options chances are the document was not broken by any of the updates. – moewe Apr 24 '18 at 15:13
  • "If you only ever used the standard styles and only modified the output via options" - you lost me there. – einpoklum Apr 24 '18 at 15:18
  • I did not know about the arXiv policy pointed out by @moewe (+1). I might have been less drastic in my recommendations had I known that. –  Apr 24 '18 at 15:35
  • Re the "If you only ever used the standard styles and only modified the output via options" I was being cautious there. To put things to the test I just compiled a document from eight years ago when I started using LaTeX and biblatex (which was at 1.0 back then and is at v3.11 now) almost worked flawlessly (that is to say it compiled the horrible code I provided it to the expected output, not that the input or output was flawless) had it not been for my hubris to mess with the deepest internals of the name format. Of course there were deprecation warnings. ... – moewe Apr 24 '18 at 15:46
  • ... I had written full-blown custom .bbx and .cbx files for the document (they redefined all bibdrivers and many bibmacros) and those did the expected thing save for the name issue where I used low-level commands. This is anecdotal, but it goes to show that you can get stability if you use high-level functions and go the extra mile to provide used definitions yourself. – moewe Apr 24 '18 at 15:54

1 Answers1

11

https://arxiv.org/help/faq/texlive.html states

Our goal is to provide a stable TeX processing system where we are able to reprocess papers from TeX source at any point in the future. arXiv maintains all past TeX trees such that existing papers are processed using the TeX tree in effect when the paper was originally submitted. This preserves the original presentation (look-and-feel) of the paper.

and later on

Users may choose to replace older documents where such updates will improve the rendering of documents impacted by bugs in the previous TL2011-based tree.

If you are replacing a paper with older TeX source that rendered fine under the previous release we strongly encourage you to carefully examine your final PDF.

This suggests that papers are rendered with the TeX live version that was used at the time of uploading. So submissions that look fine on the day of upload will continue to do so. There is nothing you have to worry about once you got arXiv to compile your document and are happy with the output.

The general way to be safe here is to use as little packages as possible. Cut down on the bells and whistles and flamboyant output. If you want to use extra packages, try to avoid low-level commands (and \makeatletter...\makeatother hackery of internals) and try to rely on high-level commands instead. High-level commands are more likely to stay stable than low-level (or even undocumented) macros.

Community
  • 1
moewe
  • 175,683