Data lineage and replicated plot in one row

Until now, the replicated plot had the width of the full page and the data
lineage graph was under it. Together they were covering more than half of
the height of the page! But the plot showing the number of papers with
tools really doesn't have too much detail, and all the space was being
wasted.

With this commit, the plot is now much much thinner and the data lineage
graph has been fitted to the right of it.

1 files changed, 15 insertions, 9 deletions

diff --git a/paper.tex b/paper.tex
index dd805f2..80c8376 100644
--- a/paper.tex
+++ b/paper.tex
@@ -293,19 +293,19 @@ Figure \ref{fig:datalineage} (bottom) is the data lineage graph that produced it
 \begin{figure*}[t]
   \begin{center}
     \includetikz{figure-tools-per-year}{width=0.95\linewidth}
-    \includetikz{figure-data-lineage}{width=0.85\linewidth}
+%    \includetikz{figure-data-lineage}{width=0.85\linewidth}
   \end{center}
   \vspace{-3mm}
   \caption{\label{fig:datalineage}
-    Top: an enhanced replica of Figure 1C in \cite{menke20}, shown here for demonstrating Maneage.
+    Left: an enhanced replica of Figure 1C in \cite{menke20}, shown here for demonstrating Maneage.
     It shows the ratio of the number of papers mentioning software tools (green line, left vertical axis) to the total number of papers studied in that year (light red bars, right vertical axis on a log scale).
-    Bottom: Schematic representation of the data lineage, or workflow, to generate the plot above.
+    Right: Schematic representation of the data lineage, or workflow, to generate the plot above.
     Each colored box is a file in the project and the arrows show the dependencies between them.
     Green files/boxes are plain-text files that are under version control and in the project source directory.
     Blue files/boxes are output files in the build directory, shown within the Makefile (\inlinecode{*.mk}) where they are defined as a \emph{target}.
     For example, \inlinecode{paper.pdf} depends on \inlinecode{project.tex} (in the build directory; generated automatically) and \inlinecode{paper.tex} (in the source directory; written manually).
     The solid arrows and full-opacity built boxes correspond to this paper.
-    The dashed arrows and low-opacity built boxes show the scalability by adding hypothetical steps to the project.
+    The dotted arrows and built boxes show the scalability by adding hypothetical steps to the project.
     The underlying data of the top plot is available at
     \href{https://zenodo.org/record/\projectzenodoid/files/tools-per-year.txt}{zenodo.\projectzenodoid/tools-per-year.txt}.
   }
@@ -380,6 +380,13 @@ Finally, to satisfy the recorded history criterion, version control (currently i
 Maneage is a Git branch that contains the shared components (infrastructure) of all projects (e.g., software tarball URLs, build recipes, common subMakefiles, and interface script).
 Derived projects start by branching off and customizing it (e.g., adding a title, data links, narrative, and subMakefiles for its particular analysis, see Listing \ref{code:branching}, there is customization checklist in \inlinecode{README-hacking.md}).
 
+The branch-based design of Figure \ref{fig:branching} allows projects to re-import Maneage at a later time (technically: \emph{merge}), thus improving its low-level infrastructure: in (a) authors do the merge during an ongoing project;
+in (b) readers do it after publication; e.g., the project remains reproducible but the infrastructure is outdated, or a bug is fixed in Maneage.
+Low-level improvements in Maneage can thus propagate to all projects, greatly reducing the cost of curation and maintenance of each individual project, before \emph{and} after publication.
+
+Finally, the complete project source is usually $\sim100$ kilo-bytes.
+It can thus easily be published or archived in many servers, for example it can be uploaded to arXiv (with the \LaTeX{} source, see the arXiv source in \cite{akhlaghi19, infante20, akhlaghi15}), published on Zenodo and archived in SoftwareHeritage.
+
 \begin{lstlisting}[
     label=code:branching,
     caption={Starting a new project with Maneage, and building it},
@@ -400,12 +407,11 @@ $ ./project make            # Re-build to see effect.
 $ git add -u && git commit  # Commit changes.
 \end{lstlisting}
 
-The branch-based design of Figure \ref{fig:branching} allows projects to re-import Maneage at a later time (technically: \emph{merge}), thus improving its low-level infrastructure: in (a) authors do the merge during an ongoing project;
-in (b) readers do it after publication; e.g., the project remains reproducible but the infrastructure is outdated, or a bug is fixed in Maneage.
-Low-level improvements in Maneage can thus propagate to all projects, greatly reducing the cost of curation and maintenance of each individual project, before \emph{and} after publication.
 
-Finally, the complete project source is usually $\sim100$ kilo-bytes.
-It can thus easily be published or archived in many servers, for example it can be uploaded to arXiv (with the \LaTeX{} source, see the arXiv source in \cite{akhlaghi19, infante20, akhlaghi15}), published on Zenodo and archived in SoftwareHeritage.
+
+
+
+