I have been looking at the three (major ?) tools---MetaPost, PStricks or pgfplots for plotting data together with LaTeX. My experience is this:

  1. MetaPost code can demand lots of lines for simple codes;

  2. Pstricks can necessitate many lines of codes also but it gives more flexibility than MetaPost and can be easier to use;

  3. pgfplots is very flexible and can require lots of lines if several options are to be included, and most likely this tool will continue evolving fast.

I am working on a project where I have a data file and I will keep on adding new data manually every year but without the number of data points getting excessively large. I am currently using MetaPost and I wonder whether my code will still work say in 10 years time. So I am looking for a tool which is robust enough so that changes that will be made will most likely NOT affect basic commands that I am using today.

I see that MetaPost and Pstricks have been here for a long time and perhaps will stay stable over the next 10 to 20 years. MetaPost seems to have some troubles handling large numbers and so PStricks seems a better choice for me.

Any comments?

  • 3
    With PGFplots, you can use compat=<version> to make the plot compile the same way, even with newer versions. I'm not sure if this backwards compatibility will be kept up indefinitely, however.
    – Jake
    Nov 25, 2011 at 6:58
  • Yes I have seen this option. For my post that you answered yesterday, I was then using compat=newest. Nov 25, 2011 at 7:01
  • 1
    I'm a bit concerned that the question is asking us to look into the future! At least as far as pgfplots is concerned, development is ongoing and so it's hard to say that nothing will ever change. Also, you are assuming that in 20 years time TeX will still be relevant at all. While that may well be the case, it's still asking use to look into the future. I'm not sure that leads to an objectively answerable question.
    – Joseph Wright
    Nov 25, 2011 at 8:08
  • Yes I agree but we can expect that Tex/LaTeX will continue to thrive in the future unless we have another Donald Knuth who comes up with a much superior typesetting system. All of MetaPost, PStricks and PGFPLOTS have lots of documentation. The concern for me is which of them will able to process current basic commands well ahead in the future. Tex/LaTeX tools and associated tools offer a good solution as we work with plain text. So if I want to store information and carry that in the future, then this is the way to go as far I can see. Nov 25, 2011 at 8:21
  • 1
    pgfplots is based on pgf/tikz and now pgfluamath arrives in the last cvs version of pgf. It's difficult to say if the introduction of lua does not change anything. It's possible to keep compatibility but perhaps to have more efficiency, some changes may occur. Nov 25, 2011 at 9:08

3 Answers 3


PSTricks and MetaPost require compiling to Postscript, whereas pgfplot is more polyvalent. I doubt Postscript will disappear, but PDF direct generation is probably more crossplatform.

I think the three utilities will still work in 10 years, anyway.

  • Thanks. Yes Postscript is pretty stable and I do always prefer the traditional postscript route even if I am using PGFPLOTS. PDF readers have evolved much from earlier versions and perhaps we can still witness many changes in the future. 1 vote up. Nov 25, 2011 at 8:02
  • 2
    as long as there are PostScript fonts and there are a lot, PostScript will be active
    – user2478
    Nov 25, 2011 at 9:43
  • metapost output can be read directly by pdftex graphics package, so it's a pdf-safe way of generating output. (note i don't know about xetex or luatex's support for metapost, but luatex has -- aiui -- a built-in metapost engine, so it's probably usable one way or another.) Nov 25, 2011 at 11:16

The TUG publishes the TeXLive DVD every year. It is possible to use a DVD from 2005 and then run a document which uses everything from this repository. Or alternatively, one can install the TUG TeXLive version in an own directory, eg on my system:

voss@shakira:~> ls -l /usr/local/texlive/
insgesamt 12
drwxr-xr-x 12 voss users 4096 22. Mai 2009  2005
drwxr-xr-x 11 voss users 4096 13. Nov 07:45 2011
drwxr-xr-x 14 voss users 4096 13. Nov 08:02 texmf-local

Pointing the $TEXMF variable to the path and linking the binaries allows to compile documents with a specific TeXLive version.

  • Yes I do that with TeXLive 2008, 2010 and 2011. I created a presentation template with a presentation package but it works only in TL2008 and I never could make it work well with TL2010 and TL2011. And so I keep TL2008 on my machine also. 1vote up. Nov 25, 2011 at 10:19
  • 2
    This seems to be more a theoretical than a practical solution. I just compare: 20 years ago I was using a 16bit system with 5¼" floppies. I guess I still have some of those floppies, but not a single 5¼" floppy drive and no DOS to install the software. Even if you keep the software it doesn't mean that you can use it. To be sure you need to keep everything, including hardware. Who knows, if we still can easily read x86 (or whatever) binaries? I guess nobody wants to compile TeXLive, this disqualifies the “but we have the souce code” argument.
    – Marco
    Nov 25, 2011 at 11:13
  • Yes this is true. We do not know what operating systems we will have in the future and then our present TeX distributions might not be installable at all. We will have to evolve with whatever the computer world has to offer us. I remember having just a couple of 3.5 inc diskettes several years ago and they sufficed in my undergraduate education. 1 vote up. Nov 25, 2011 at 11:32

This answer is only related to pgfplots (as I am the author of pgfplots, I feel privileged to answer only this side-aspect of your question).

Pgfplots is being developed with backwards compatibility in mind. There are always decisions to make between general availability of new features or backwards compatibility - and I am working hard to keep a "reasonable" balance (typically by means of the \pgfplotsset{compat={<version>} approach).

So, the answer is: pgfplots will maintain backwards compatibility, but will keep introducing new features (which may need manual activation if they might introduce backwards compatibility problems.).

Anything which breaks backwards compatibility is supposed to be a bug and should be reported as such. I hope there are only very few of these.

  • Thanks for this VERY useful information. It is important for users to know if today's codes will work in the future as well. 1 vote up. Nov 28, 2011 at 6:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .