Declared glyph widths must match the font program

PDF/UA check FONT_GLYPH_WIDTH_CONSISTENT · Fonts & text encoding · severity Medium · PDF/UA 8.4.5.6 Widths · advanced check

↩ Back to the rules index · WCAG cross-reference

Advanced check. This is a file-internals rule. It is hidden from the standard report view and generally indicates a problem with the tool that produced the PDF rather than something an author did.

Why it matters#

Width mismatches cause incorrect cursor positioning, text selection drift, and broken word boundaries when text is extracted.

What you will see#

The Widths array in the font dictionary disagrees with the widths inside the embedded font program.

How to fix#

Correct the Widths array (or W array for CID fonts) in the font dictionary so each value matches the advance width of the same glyph in the embedded font program, within 1/1000 text-space unit. Re-embedding the font with a tool that derives widths from the font program fixes all entries at once.

Step-by-step guide#

1. Identify the fonts and glyphs where the Widths array (or W array for CID fonts) in the font dictionary differs from the advance widths stored in the embedded font program by more than 1/1000 text-space unit - the tolerance PDF/UA-2 clause 8.4.5.6 allows.
2. Prefer re-exporting the document from its authoring application with a current PDF exporter, which derives the width arrays directly from the font program and avoids any layout shift.
3. If re-export is impossible, the width arrays were written incorrectly by the producing application - the Widths or W and DW values do not match the advance widths in the embedded font program (hmtx table for TrueType, CFF metrics for Type 1/CFF) - and the only reliable fix is regenerating the file from its source with a compliant export pipeline.
4. For Type 0 fonts rendered in vertical writing mode, also make the DW2 and W2 vertical-metrics keys of the descendant CIDFont consistent with the vertical metrics (vmtx) in the embedded font program, as 8.4.5.6 requires.
5. After correcting the arrays, proof the affected pages - viewers position glyphs using the dictionary widths, so fixing wrong values can visibly change spacing; if the layout breaks, fixing at the source is the safer route.
6. Acrobat Pro has no editor for width arrays; this fix requires regenerating the file from its source with a compliant export pipeline.

Verify: Re-run the EQChecker advanced scan and confirm FONT_GLYPH_WIDTH_CONSISTENT reports zero errors. Proof the pages visually - selection highlights and cursor positions should now track the glyphs exactly.

Note: Glyphs referenced only with text rendering mode 3 (invisible text, e.g. OCR layers under scanned images) are explicitly exempt from this requirement per 8.4.5.6. Width mismatches most often come from font substitution during ad-hoc PDF edits or from merged documents mixing versions of the same font.

WCAG success criteria#

No WCAG success criterion maps cleanly to this check — it is a PDF/UA structural requirement. The PDF/UA clause above is the normative reference.

Standards#

This check contributes to the following standards:

PDF/UA