diff --git a/graph/graph/graph.lp2.rkt b/graph/graph/graph.lp2.rkt
index 957743ae..b22f796a 100644
--- a/graph/graph/graph.lp2.rkt
+++ b/graph/graph/graph.lp2.rkt
@@ -125,7 +125,7 @@ desired result node, we can use the node's name as the transform name. We should
 think about naming conflicts: when calling @tc[n], should it insert a link
 request for the transform, or should it create an incomplete node?
 
-@subsection[#:tag "complex-transforms-return-type-conclusion"]{Conclusion}
+@subsection[#:tag "graph|complex-transforms-return-type-conclusion"]{Conclusion}
 
 With this approach, we can write the graph creation macro with the guaranty
 that the result of a transform always is exactly one node type. More complex
diff --git a/graph/graph/queue.lp2.rkt b/graph/graph/queue.lp2.rkt
index 41336edd..5ad450ec 100644
--- a/graph/graph/queue.lp2.rkt
+++ b/graph/graph/queue.lp2.rkt
@@ -13,15 +13,15 @@ the list being processed. In other words, we want to apply a @tc[lambda] to all
 elements inside a queue, with the possibility to return new elements that should
 be added to the queue.
 
-We will first define a general version in section @secref{sec:general}, where
+We will first define a general version in section @secref{queue|general}, where
 most implementation details are parametrizable. We then use this as a building
 block to define more specialized version, for example the section
-@secref{sec:sets-add} defines a version where the queue is a set, and elements
+@secref{queue|sets-add} defines a version where the queue is a set, and elements
 can only be added to the queue, not removed (therefore the @tc[lambda] is
 expected to return only the elements to be added, and not the ones already
 present in the queue).
 
-@section[#:tag "sec:general"]{General version}
+@section[#:tag "queue|general"]{General version}
 
 Since both lists, sets and other structures could be used to represent the
 queue, we don't specify them here, and instead take the @tc[dequeue] and
@@ -35,10 +35,10 @@ result for this element with the remaining ones, either by constructing the
 overall result in the @tc[accumulator], or by using the value returned by
 @tc[rec].
 
-The former case is shown in section @secref{sec:tail-call-reverse-map}, where
+The former case is shown in section @secref{queue|tail-call-reverse-map}, where
 each element's result is combined with the accumulator using @tc[cons], whereas
-the latter case is shown in @secref{sec:map}, where the result for an element is
-combined with @tc[cons] to what @tc[process-rest] will return.
+the latter case is shown in @secref{queue|map}, where the result for an element
+is combined with @tc[cons] to what @tc[process-rest] will return.
 
 The lambda @tc[process] takes four parameters: the @tc[element] to process, the
 current accumulator, current queue, and a function to call recursively with the
@@ -76,7 +76,7 @@ some of those need to be deleted before being processed).
                (% element rest-queue = (dequeue queue)
                   (process element accumulator rest-queue process-rest)))))]
 
-@section[#:tag "sec:map"]{@racket[map]}
+@section[#:tag "queue|map"]{@racket[map]}
 
 Here is a version that behaves like @tc[map] on the queue, returning a list of
 the result of @tc[process] on the queue's elements, in the order in which they
@@ -116,8 +116,8 @@ be discarded once all elements have been processed), and the @tc[new-queue].
             (→ Element Accumulator Queue (→ Queue Accumulator (Listof Result))
                (Listof Result)))]
 
-@section[#:tag "sec:tail-call-reverse-map"]{Tail-call @racket[map], with results
- in reverse order}
+@section[#:tag "queue|tail-call-reverse-map"]{Tail-call @racket[map], with
+ results in reverse order}
 
 @chunk[<tail-call-reverse-map-queue>
        (: tail-call-reverse-map-queue
@@ -153,7 +153,7 @@ be discarded once all elements have been processed), and the @tc[new-queue].
             (→ Element RAccumulator Queue (→ Queue RAccumulator (Listof Result))
                (Listof Result)))]
 
-@section[#:tag "sec:sets-add"]{Variant using sets}
+@section[#:tag "queue|sets-add"]{Variant using sets}
 
 We define in this section a fold over queues represented using sets. This
 version also disallows removing elements from the queue by making the union of
diff --git a/graph/graph/rewrite-type.lp2.rkt b/graph/graph/rewrite-type.lp2.rkt
index 5ba7c83f..2fd0ff4d 100644
--- a/graph/graph/rewrite-type.lp2.rkt
+++ b/graph/graph/rewrite-type.lp2.rkt
@@ -5,7 +5,7 @@
 
 @title[#:style manual-doc-style]{Rewriting data structures and their types}
 
-@section[#:tag "sec:intro-example"]{Introductory example}
+@section[#:tag "rewrite-type|intro-example"]{Introductory example}
 This module allows purely functional substitution inside a data structure of
 arbitrarily deep elements of a given type, while also computing the type of the
 result.
@@ -75,7 +75,7 @@ return type containing no more strings, and the correct return value.
                            Number)))
         '(((tag2 (#(sym) 7 (2 3 4))) . 1)))]
 
-@section[#:tag "sec:replace-in-type"]{Replacing parts of a type}
+@section[#:tag "rewrite-type|replace-in-type"]{Replacing parts of a type}
 
 The @tc[replace-in-type] @tc[for-syntax] function is pretty straightforward: it
 checks whether the given type matches one of the substitution rules given in
@@ -125,13 +125,14 @@ The other cases use @tc[~literal] and a syntax pattern to find uses of
 TODO: If the type is a quoted primitive, we should replace it too, for example
 @tc['("abc" symbol)] should be transformed into @tc['(3 symbol)] if we apply the
 @tc[[String Number string-length]] substitution from the example in section
-@secref{sec:intro-example}.
+@secref{rewrite-type|intro-example}.
 
 @CHUNK[<replace-in-type-case-quote>
        [((~literal quote) a)
         #`(quote a)]]
 
-@section[#:tag "sec:replace-in-instance"]{Replacing parts of an instance}
+@section[#:tag "rewrite-type|replace-in-instance"]{Replacing parts of an
+ instance}
 
 The @tc[replace-in-instance] for-syntax function is defined in a similar way,
 with an internal definition for @tc[recursive-replace]. The case of unions is
@@ -251,7 +252,7 @@ detail in the
                "Rethink-how-to-do-the-multi-step-types-more-inside")]
 {FogBugz case 54}.
 
-@section[#:tag "sec:fold"]{Folding over an instance}
+@section[#:tag "rewrite-type|fold"]{Folding over an instance}
 
 Replacing parts of an instance may require first extracting them. We define here
 a general fold over some data structures, that allows the replacement function
@@ -532,12 +533,12 @@ type.
 @section{Replacing parts of an instance using fold}
 
 We can use the @tc[fold-instance] for-syntax function defined in section
-@secref{sec:fold} as a building block to write a new, simpler definition of the
-@tc[replace-in-instance] for-syntax function defined in section
-@secref{sec:replace-in-instance}. This method should give better consistency
-between the behaviour of @tc[replace-in-instance] and @tc[fold-instance] as well
-as better maintainability, but is slightly less efficient than the separate
-implementation.
+@secref{rewrite-type|fold} as a building block to write a new, simpler
+definition of the @tc[replace-in-instance] for-syntax function defined in
+section @secref{rewrite-type|replace-in-instance}. This method should give
+better consistency between the behaviour of @tc[replace-in-instance] and
+@tc[fold-instance] as well as better maintainability, but is slightly less
+efficient than the separate implementation.
 
 @CHUNK[<replace-in-instance2>
        (define-for-syntax (replace-in-instance2 val t r)
diff --git a/graph/graph/structure.lp2.rkt b/graph/graph/structure.lp2.rkt
index 09746b66..9ac54a3c 100644
--- a/graph/graph/structure.lp2.rkt
+++ b/graph/graph/structure.lp2.rkt
@@ -9,7 +9,7 @@
 @section{@racket[define-structure]}
 
 Structures are represented using regular racket @tc[struct]s, see
-@seclink["structures" #:doc "type-system.scrbl"]{the overview document}.
+@seclink["type-system|structures"]{the overview document}.
 @;secref["structures" #:doc "type-system.scrbl"].
 
 @chunk[<structure>
@@ -90,11 +90,11 @@ We wish to pre-declare all @tc[struct] types for various reasons:
 
 In order to pre-declare the @tc[struct]s, we need to remember them across
 compilations, for that we use @tc[remember-all] and @tc[get-remembered] defined
-below in section @secref{remember}. We then need to make these identifiers
-available in the correct syntax scope. The easiest way to do that, is to have a
-private macro @tc[(declare-all-structs (name field ...) ...)] which does all the
-required definitions, namely defining the struct, as well as @tc[make-struct],
-@tc[get-field], and the match-expander eventually.
+below in section @secref{structure|remember}. We then need to make these
+identifiers available in the correct syntax scope. The easiest way to do that,
+is to have a private macro @tc[(declare-all-structs (name field ...) ...)] which
+does all the required definitions, namely defining the struct, as well as
+@tc[make-struct], @tc[get-field], and the match-expander eventually.
 
 We do not wish to remember the type of each field, as they may be a non-exported
 identifier from some module. It should not cause any problem when declaring the
@@ -343,7 +343,8 @@ instead of needing an extra recompilation.
                           b)
                      "b")]
 
-@section[#:tag "remember"]{Closed-world assumption and global compilation}
+@section[#:tag "structure|remember"]{Closed-world assumption and global
+ compilation}
 
 In order to be able to access elements in the list as deep as they can be, we
 need to know the length of the longest structure used in the whole program. 
diff --git a/graph/graph/type-system.scrbl b/graph/graph/type-system.scrbl
index 0c8760e8..71a2ff41 100644
--- a/graph/graph/type-system.scrbl
+++ b/graph/graph/type-system.scrbl
@@ -6,7 +6,7 @@
 
 @;(table-of-contents)
 
-@section[#:tag "structures"]{Structures}
+@section[#:tag "type-system|structures"]{Structures}
 
 @;(+ 1 2 3) gives @(format "~a" (+ 1 2 3)).
 
diff --git a/graph/lib/doc/example.lp2.rkt b/graph/lib/doc/example.lp2.rkt
index 65ae1c04..f35d82f4 100644
--- a/graph/lib/doc/example.lp2.rkt
+++ b/graph/lib/doc/example.lp2.rkt
@@ -14,9 +14,9 @@
 
 @section{A section}
 
-In section @secref{sec:foo} we present, blah blah.
+In section @secref{doc/example|foo} we present, blah blah.
 
-@subsection[#:tag "sec:foo"]{My subsection}
+@subsection[#:tag "doc/example|foo"]{My subsection}
 
 @$${\frac{2x}{x^2}}
 @(colorize (filled-ellipse 30 15) "blue")
diff --git a/graph/make/make.rkt b/graph/make/make.rkt
index ed40dcf4..2b998f03 100644
--- a/graph/make/make.rkt
+++ b/graph/make/make.rkt
@@ -159,11 +159,13 @@
                     [html html-files])
           (html)
           (scrbl-or-lp2)
+          ;; TODO: compile twice, so that the cross-references are correct
           (scribble scrbl-or-lp2 doc-sources "--html"))
         (for/rules ([scrbl-or-lp2 doc-sources]
                     [pdf pdf-files])
           (pdf)
           (scrbl-or-lp2)
+          ;; TODO: compile twice, so that the cross-references are correct
           (scribble scrbl-or-lp2 doc-sources "--pdf"))
         (for/rules ([mathjax-link mathjax-links])
           (mathjax-link)
diff --git a/graph/type-expander/type-expander.lp2.rkt b/graph/type-expander/type-expander.lp2.rkt
index 79f6196a..c8922cb3 100644
--- a/graph/type-expander/type-expander.lp2.rkt
+++ b/graph/type-expander/type-expander.lp2.rkt
@@ -260,7 +260,7 @@ Shadowing and @tc[∀] variables:
 Througout this section, we provide alternative definitions of the
 @tc[typed/racket] forms @tc[:], @tc[lambda], @tc[define], @tc[struct], @tc[ann],
 @tc[inst]… . We write these definitions with @tc[syntax-parse], using the syntax
-classes defined in section @secref{syntax-classes}.
+classes defined in section @secref{type-expander|syntax-classes}.
 
 Most of the time, we will use the experimental @tc[template] macro from
 @tc[syntax/parse/experimental/template] which allows more concise code than the
@@ -286,7 +286,7 @@ after expanding the type argument.
        (: c0 `(2 "abc" #,,(Pairof (U 'x 'y) (U 'y 'z)) #(1 "b" x) d))
        (define c0 '(2 "abc" #,(x . z) #(1 "b" x) d))]
 
-@subsection[#:tag "syntax-classes"]{syntax classes}
+@subsection[#:tag "type-expander|syntax-classes"]{syntax classes}
 
 The syntax classes from @tc[typed-racket/base-env/annotate-classes] match
 against the @tc[:] literal. Since we provide a new definition for it, the syntax
@@ -674,7 +674,8 @@ them.
          (check-equal? ((make-predicate (Repeat Number 3)) '(1 2 3)) #t)
          (check-equal? ((make-predicate (Repeat Number 3)) '(1 "b" 3)) #f))]
 
-@subsection[#:tag "other-forms"]{Other @racket[typed/racket] forms}
+@subsection[#:tag "type-expander|other-forms"]{Other @racket[typed/racket]
+ forms}
 
 The other @tc[typed/racket] forms below do not have an alternative definition
 yet.
@@ -784,7 +785,7 @@ yet.
 @section{Future work}
 
 We have not implemented alternative type-expanding definitions for all the
-@tc[typed/racket] forms, as noted in @secref{other-forms}.
+@tc[typed/racket] forms, as noted in @secref{type-expander|other-forms}.
 
 Integrating the type-expander directly into typed/racket would avoid the need to
 provide such definitions, and allow using type-expanders in vanilla