Odtnhj

Welcome to TeX.SE! I think there is not a default answer to your question per se. It more likely depends on the fact how you perceive TeX itself. If you merely view it as a system to format your text and structure your document, you are very likely to adopt the workflow to generate plots using your programming language than a system that it tightly integrated with TeX.

The viewpoint I, as a PhD student in signal processing, usually take instead is the following: I use TeX as a means of formatting and presenting my whole work and results in an appropriate fashion. This means that not only to I typeset my thoughts and arguments in TeX but also the simulation results and visualizations I can come up with.

That being said, I usually proceed the following way when it comes to plots:

1. I write a whole bunch of simulation scripts that usually produce several MB of files containing some multidimensional simulation results and their parameters. These scripts tend to take very long computation wise and generate a whole bunch of data.


2. I write an a lot smaller script that does the simulation data processing and this script produces two things. First it produces some very ugly plots, which only serve me as means of quickly debugging the data and the simulations in 1. And second at least one *.csv file, which usually only is a few KB only containing the data and parameters I actually want to plot. This can stem from averaging or applying some other kind of statistics to the data from 1.


3. I use this *.csv file to generate plots using PGF by loading the data from it, which I can easily plug into a poster template, a beamer template or a paper template and a nicely composed selection of macros and color schemes make everything look very integrated with the rest of the document at hand.

What are the advantages of this approach you might ask and very rightfully so, since it seems to introduce one additional layer of complexity. The reasons for me doing this are in ascending order of importance

1. It makes simulation data analysis more transparent, since it separates data generation from data evaluation.


2. It makes my workflow more flexible, since the separation of simulation and evaluation allows one of the two to change without affecting the other. Especially when simulations take long, it is of tremendous value that the post-processing is decoupled from them.


3. It forces me to think about the data structures within my simulation, which results in a more structured workflow itself.


4. The decoupling of the post-processing (generating the *.csv-files) from the plotting yields again a more flexible workflow. After having generate all the data you need, you never ever have to touch it. It is just there and you can focus in TeX on the visualization.


5. All data visualization parameters, so the parameters of your plots are at one place – in the TeX code – making it easier not to loose your mind.

Summarizing, it simply gives you more freedom, while also enforcing a more streamlined but structured workflow and puts things where they should be (IMHO), since programming is for data generation and TeX is amazing at making things look beautiful! :-)

EDIT: When collaborating with others it also is of tremendous value. If you only hand out raw or processed simulation results (which you can handle with git or any other similar tool quite nicely), you make it easier for others to modify the presentation of the data, since they do not need to run any code external to TeX to get things going.

The main reason is to match the text, as you already said, but also the arrow tips or other similar symbols.

Another reason (valid in my case) is "not to have another tool for plotting graphs available".

Another advantage is that all lines will have the same width. Graphs produced by external tools are often scaled during the inclusion in the document to fit them in the available textwidth or similar. This will change the width of their lines.

PGFPlots has quite a few advantages. It does not only provide pretty graphs and tables, but also a bit of handling of data (csv reader, and a possiblity to embed the data direct in the document), such that you're sure that your tables and plots always show the same data. It also can calculate regressions and a lot more (see their examples gallery).

It is one nice way to do such things.

It also mentioned that no other plotting packages from R or python can generate graphs that have the same high image quality as those generated by pgfplots in LaTeX directly, but no examples or reasons were given. Is there evidence to back up this claim?

No. I created nice looking documents by embedding PDF/EPS generated with gnuplot and matplotlib (python). Some of them look more modern than pgfplots tables. Still it requires a bit more complicated build process (I use makefiles for this) and more experimenting until everything matches, padding and margin are nice and the fonts look the same.

PGFPlots is "just" a LaTeX package and follows the same philosophy, that you should not need to handle the details, but just provide the data and it will produce something nice looking.

For other functions of PGFPlots and TikZ than tables and plots I often prefer using SVGs (use inkscape for high-quality PDF export). They are not automatically generated, but you have more control over the look without using many TeX commands.

Something I used for the first time recently when writing a large and complicated report with numerous tables and graphs.

All the data was contained in spreadsheets and was adapted frequently. I exported the data from the spreadsheets using python. The python scripts directly created pgfplots syntax. I still have to create a makefile to re-extract data when something has changed before compiling the Latex file, but that is a detail.

My old way of doing this was to generate data files, GNUplot script files, run GNUplot and include the graphs in my Latex document.

Creating directly PGFplots skips two steps and simplify maintenance: avoid separate data files and the maintenance of the GNUplot files. The latter is by no means a small task, as it is harder to get the GNUplot output right to match the Latex document. When the graph syntax is in the Latex file it is much easier to develop, adjust and maintain.

Also quite relevant was that I had to include many graphs in my presentation with the same contents. It was done very quickly to include the same Tikz pictures in my Beamer slides. Although for correct presentation I had to include
this in the presentation:

begintikzpicture
beginscope[scale=0.6]
%code goes here
endscope
endtikzpicture

The scale is quite right while keeping everything else in the correct sizes. In a report the graphs need to be somewhat smaller. (Don't ever use shrink in Beamer!)

Last but not least, I had expected PGFplots to get slow on large data collections. It does not. Whereas I still have some PDFs to include from, created from SVG. That really slows down Latex compilation.

Separating input files (for generating PSTricks diagrams) from main input file (for writing the main document) is my recommended best practice because the diagram can be compiled separately to yield PDF outputs, so

• compiling the main input file importing the PDF diagram become much much faster.




• we can reuse the same diagram across many projects with consistent settings.




• the main input file become much much readable and easy to maintain because the cluttering diagram code no longer exist. I call it separation of concern!

Diagrams created with PSTricks can use the same font used in the main input file by creating a private auxiliary package that is only for font inclusion for either diagram input files or main input file.

It also mentioned that no other plotting packages from R or python can generate graphs that have the same high image quality as those generated by pgfplots in LaTeX directly, but no examples or reasons were given. Is there evidence to back up this claim?

With respect R (phyton ignorant here!), there are a huge evidence of its ability to make of almost any type of graphs. As a small sample, the R graph gallery seem enough.

With respect to the printing quality, R can make graphs in bitmap formats (png, jpeg, bmp, tiff) than of course could have a poor quality when zoomed excessively in LaTeX or in another format, but the grDevices documentation states than R can also make vectorial images in xfig, ps, wmf, pdf and that other packages can include other devices outputting SVG and PGF/TiKZ, and even TeX/PicTeX files "(of historical interest only)".

To be practical, let's focus in PDF format: Are vectorial images that can be included directly in LaTeX documents, so the printing quality will by only limited by the printer resolution in dpi. But also can include LaTeX expressions in labels of R plots using R functions as TeX().

The only question then could be that sans serif default font of labels and axis of R plots does not match with the default roman "Computer Mode" font of LaTeX text. This could be regarded as a good "feature" (I really like a different font for plots) or a terrible "bug". In the last case, one solution could be change the PDF font type in R. In my Linux system, that could be one of ...

> names(pdfFonts())
 [1] "serif" "sans" "mono" 
 [4] "AvantGarde" "Bookman" "Courier" 
 [7] "Helvetica" "Helvetica-Narrow" "NewCenturySchoolbook"
[10] "Palatino" "Times" "URWGothic" 
[13] "URWBookman" "NimbusMon" "NimbusSan" 
.... etc .....

So I can make:

> par(family="Palatino") # For example 
> plot(c(1,2,3),main="Plot with Times font")

This is only a example. It is also possible use any TT or OTF font in other ways. In any case, if that font does not match exactly with the LaTeX font, of course you can also change the LateX font, even to the same TT or OTF font using xelatex or lualatex.

But if the look and feel do not match still enough, or simply you do want to deal with fonts in one or both sides, a simpler solution is use knitr with the tikz device. The main reason of knitr is be better than Sweave embedding R source in LaTeX documents.

For those that do not know what I'm talking about, just explain that this mixed document (LateX+R) usually have the .Rnw extension (mean "R noweb" format) and can be exported by R to a pure LaTeX document (the .tex version) where the R code is replaced by the R output (optionally with echo of source R code, beautifully highlighted) that can be processed by LaTeX compilers as usually (with Rstudio editor all the process is just press one button). This means that if the data changed, just a new export-compilation of the document will update all plots, and always in concordance with any tables and text results generated automatically by R.

With respect to the examples of R plots, there are many in this, somo site using knitr and the tikz device, as this 2D plot and these
3D (or 4D) plots (sorry for the autocites).

Beside be scalable images with LaTeX fonts, that LaTeX+R approach with a powerful statistical environment behind the scenes is a main reason to go with R plots, as this allow a reproducible research.

With respect python (phyton ignorant here!) I can say only that knitr
is able to manage chunks of python (see Can we import Python file in latex? ) in a .Rnw file, so probably similar considerations can be made about their plots.

PGFPLOTS enables very precise control of line weights and the positioning of labels on charts, as well as exact control of the fonts used. For my purposes, this is great for plotting curves from various equations; and, as an opinion, the results can reach the quality formerly associated with engineering draftsmen (and largely lost when the world switched to Excel and its cousins). It's also nice that the charts are vectorized and infinitely scalable, and that (under Lualatex) one can integrate Lua code (or C code via FFI) into the computation and plotting of complex formulae.

For really simple drawings, PGFPLOTS is a lot more work than pasting up and exporting from PowerPoint.