Skip to content

docs: per-page scoped labels to fix cross-page :ref: resolution#10

Open
petrkalina wants to merge 2 commits into
dcm4che:masterfrom
petrkalina:per-page-scoped-labels
Open

docs: per-page scoped labels to fix cross-page :ref: resolution#10
petrkalina wants to merge 2 commits into
dcm4che:masterfrom
petrkalina:per-page-scoped-labels

Conversation

@petrkalina

Copy link
Copy Markdown

Problem

When the same .. _label: is declared in multiple .rst files (e.g. dcmRulePriority lives in 7 different config pages), Sphinx picks one as the canonical target for :ref: resolution. All other pages' :ref:\title `` calls resolve to that single page.

User-visible effect: clicking Rule Priority in the Archive Attribute Coercion table jumps to studyRetentionPolicy.html#dcmrulepriority instead of staying on the current page. This affects 221 of 731 attribute labels (~30%) — worst offenders include dcmProperty (24 files), cn (20), dicomDescription (12), dcmURI (11), dicomAETitle (10).

Fix — Option B (preserves external URLs)

For every existing .. _attrName: declaration, stack a per-page-scoped twin below it:

    .. _dcmRulePriority:
    .. _archiveAttributeCoercion-dcmRulePriority:

Then rewrite intra-file :ref:\text `` calls to use the scoped form:

:ref:`Rule Priority <archiveAttributeCoercion-dcmRulePriority>`

Sphinx now resolves the :ref: per page (no more dedup ambiguity). The original .. _attrName: label stays put, so the rendered HTML emits both anchor IDs side by side — existing external links that hard-coded the old anchor (e.g. archiveAttributeCoercion.html#dcmrulepriority) keep working unchanged.

conf.py: added suppress_warnings = ['ref.label'] so the now-intentional duplicate bare labels don't spam the build log.

Stats

Count
.rst files changed 76
Scoped labels added 1,165
:ref: references rewritten 1,135
Duplicate-label warnings before many (was part of the ~50 warning baseline)
Duplicate-label warnings after (suppressed) 0

Verification (local Sphinx 5.0 build with sphinx_rtd_theme==1.0.0)

archiveAttributeCoercion.html rendered HTML for Rule Priority row:

<p id="archiveattributecoercion-dcmrulepriority">   <!-- new scoped anchor -->
  <span id="dcmrulepriority"></span>                <!-- old anchor preserved -->
  <a href="#archiveattributecoercion-dcmrulepriority">Rule Priority</a>
</p>

Same row on studyRetentionPolicy.html now also links to its own #studyretentionpolicy-dcmrulepriority — i.e. each page resolves locally.

External URLs that consumers may have bookmarked (archiveAttributeCoercion.html#dcmrulepriority, archiveNetworkAE.html#dcmretrieveaet, etc.) continue to work because the legacy id= attributes are still emitted on every page.

Reproducibility

The rewrite is idempotent. The script that produced the diff is included at tools/rewrite_labels.py — re-running it against docs/ is a no-op once applied.

Companion repo

The HL7 conformance statement (dcm4chee-arc-hl7cs) was checked — its labels are all unique across pages, so this fix isn't needed there.

…rity, etc.)

When the same label name (e.g. .. _dcmRulePriority:) is declared in
multiple .rst files, Sphinx resolves all :ref:`title <label>` calls to
a single canonical page. Result: clicking "Rule Priority" on
archiveAttributeCoercion.html jumps to studyRetentionPolicy.html
instead of staying on the current page. 30% of labels (221/731) are
affected.

This commit adds a per-page-scoped twin label below every existing
label declaration (e.g. .. _archiveAttributeCoercion-dcmRulePriority:)
and rewrites the intra-file :ref: targets to use the scoped form. The
original bare label is preserved so external URLs that hard-coded the
old anchor (e.g. archiveAttributeCoercion.html#dcmrulepriority) keep
working — the HTML emits both anchor IDs side by side.

conf.py: add suppress_warnings = ['ref.label'] so the now-intentional
duplicate bare labels do not flood the build output.

Stats:
  files changed: 76
  scoped labels added: 1165
  refs rewritten: 1135

Generated by tools/rewrite_labels.py (script attached in PR).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant