Adds hyperlinks to documentation

doc/latex/cta.tex

@@ -25,7 +25,16 @@
 \usepackage{tikz-uml} % See README.md
 \usepackage{SIunits}
 \usetikzlibrary{positioning}
-%\usepackage{hyperref}
+
+% Hyperlinks
+
+\usepackage{hyperref}
+\hypersetup{
+  colorlinks=true,
+  linkcolor=blue,
+  pdftitle={The CERN Tape Archive},
+  unicode=true
+}
 
 % Glossary
 

doc/latex/cta_Introduction.tex

@@ -4,8 +4,8 @@ The main objective of the \gls{cta} project is to develop a prototype tape archi
 between remote disk storage systems and tape drives. The concrete remote storage system of choice is \gls{eos}.
 
 The \gls{dss} currently provides a tape archive service. This service is implemented by the \gls{hsm} system
-named the \gls{castor}. This \gls{hsm} has an internal disk-based storage area that acts as a staging area for
-tape drives. Until now this staging area has been a vital component of \gls{castor}. It has provided the necessary
+named the \gls{castor}. This \gls*{hsm} has an internal disk-based storage area that acts as a staging area for
+tape drives. Until now this staging area has been a vital component of \gls*{castor}. It has provided the necessary
 buffer between the multi-stream, block-oriented disk drives of end users and the single-stream, file-oriented tape
 drives of the central tape system.  Assuming the absence of a sophisticated disk to tape scheduling system, at any
 single point in time a disk drive will be required to service multiple data streams whereas a tape drive will only
@@ -15,16 +15,16 @@ the need for a tape archive system to have an internal disk-based staging area h
 striped over multiple disk servers means that all of these disk-servers can be used in parallel to transfer that
 file to a tape drive, hence using multiple disk-drive streams to service a single tape stream.
 
-The \gls{cta} project is a prototype for a very good reason. The \gls{dss} group needs to investigate and learn
+The \gls*{cta} project is a prototype for a very good reason. The \gls*{dss} group needs to investigate and learn
 what it means to provide a tape archive service that does not have its own internal disk-based staging area. The
-project also needs to keep its options open in order to give the \gls{dss} group the best opportunities to identify
+project also needs to keep its options open in order to give the \gls*{dss} group the best opportunities to identify
 the best ways forward for reducing application complexity, easing code maintenance, reducing operation overheads
 and improving tape efficiency.
 
-The \gls{cta} project currently has no constraints that go against collecting a global view of all tape, drive and
-user request states. This means the \gls{cta} project should be able to implement intuitive and effective tape
+The \gls*{cta} project currently has no constraints that go against collecting a global view of all tape, drive and
+user request states. This means the \gls*{cta} project should be able to implement intuitive and effective tape
 scheduling policies.  For example it should be possible to schedule a tape archive mount at the point in time
-when there is both a free drive and a free tape. The architecture of the \gls{castor} system does not facilitate
+when there is both a free drive and a free tape. The architecture of the \gls*{castor} system does not facilitate
 such simple solutions due to its history of having separate staging areas per experiment and dividing the mount
 scheduling problem between these separate staging areas and the central tape system responsible for issuing tape
 mount requests for all experiments.