Superscript detection in Azure Content Understanding and other findings.

Azure Document Intelligence cannot preserve superscript formatting; the supported workaround is to classify likely superscripts from word polygons by comparing each word’s vertical position with adjacent words on the same line.

1. Superscript citation markers

Microsoft lists superscript detection as a current Document Intelligence OCR limitation affecting all models: raised characters are returned as ordinary inline text, and custom-model training does not resolve it. The recommended mitigation is to compare the polygon or boundingBox coordinates of adjacent word spans and identify words whose baseline is significantly elevated relative to the surrounding line.^1^

The styles output does not provide a superscript property. Standard style detection only identifies handwriting; the styleFont add-on adds properties such as font family, weight, italic style, foreground color, and background color, but not baseline shift or superscript semantics.^2^^3^

A practical detector should use geometry first, then apply citation-specific rules only to geometrically raised candidates:

def likely_superscript(word, line_words, rise=0.25, size_ratio=0.85):
    def bounds(p):
        xs, ys = p[[IP Address]], p[[IP Address]]
        return min(xs), min(ys), max(xs), max(ys)

    _, top, _, bottom = bounds(word["polygon"])
    peers = [bounds(w["polygon"]) for w in line_words if w is not word]
    baseline = sorted(p[3] for p in peers)[len(peers) // 2]
    median_h = sorted(p[3] - p[1] for p in peers)[len(peers) // 2]
    height = bottom - top

    return bottom < baseline - rise * median_h and height < size_ratio * median_h

For production use:

1. Group words by page and line.
2. Estimate the line baseline robustly from ordinary words, excluding punctuation and outliers.
3. Flag a token only when it is both elevated and smaller than neighboring text.
4. Apply domain rules afterward—for example, a raised integer following a word or punctuation near a paragraph end.
5. Retain the original content, polygon, confidence, and inferred status rather than rewriting the source text irreversibly.

Content Understanding documents word source, span, and confidence, but its documented element schema does not expose superscript metadata. Therefore, the observed Demovexa.3 result cannot currently be disambiguated from text alone; geometry-aware post-processing or a second OCR pass is required.^4^

2. Footnote markers and symbols

ocrHighResolution is the appropriate Document Intelligence add-on for small, dense, or graphically mixed text. It can improve character extraction, but it does not add superscript semantics.^3^

POST {endpoint}/documentintelligence/documentModels/prebuilt-layout:analyze
     ?api-version=2024-11-30
     &features=ocrHighResolution

For symbols and footnote markers, retain per-word confidence and send low-confidence or geometrically unusual spans to targeted review. OCR accuracy varies with resolution, contrast, rotation, character size, and density.^5^

Formula extraction is useful for actual mathematical expressions and returns LaTeX plus polygon coordinates, but it should not be treated as a general citation-marker detector.^3^

3. Figure detection

The documented products do support different figure-processing paths:

• Document Intelligence Layout returns figure bounding regions, related spans/elements, captions, and—when output=figures is requested—cropped figure images.^6^
• Content Understanding exposes figures, but figure description and chart/diagram analysis are optional. Enable enableFigureDescription and enableFigureAnalysis in the analyzer configuration when the downstream LLM needs semantic figure content.^4^

Those options enrich figures that are detected; they do not guarantee that a region misclassified as text will become a figure. For documents matching the example, using ADI Layout as the figure-localization stage and passing its cropped figure output to the downstream multimodal model is the safer pipeline.

4. Very long single-page PDFs

The documented image dimension range for both services is 50 × 50 through 10,000 × 10,000 pixels. ADI also requires approximately 12-pixel text height for a 1024 × 768 image.^6^ Content Understanding accepts asynchronous PDFs up to 200 MB and 300 pages, but those limits do not guarantee good OCR on an unusually tall single rendered page.^7^

Pre-splitting the tall page is therefore reasonable. To reduce boundary damage:

• Detect whitespace or low-content horizontal bands and cut there.
• Add vertical overlap between tiles.
• Preserve each tile’s original-page Y offset.
• Deduplicate overlapping words using normalized text plus polygon overlap.
• Avoid cuts through tables and detected figure regions.
• Reassemble results by original-page coordinates rather than treating tiles as unrelated pages.

These examples are useful product feedback, particularly the reproducible ACU figure miss and superscript flattening. Include the original file, API version, analyzer configuration, raw JSON, and expected polygons when reporting them; the screenshots alone do not preserve enough information to reproduce geometry-sensitive behavior.

References

1. Azure Document Intelligence known issues and troubleshooting
2. Analyze document API response
3. Document Intelligence add-on capabilities
4. Document analysis: Extract structured content
5. Transparency note and use cases for Document Intelligence
6. What is the Document Intelligence layout model?
7. Azure Content Understanding in Foundry Tools service quotas and limits