Matterhorn 12-001 · PDF/UA-1 UA1:7.2-4

Stretched brackets and kashida: one character, many glyphs

Glyphs stretched to fill space — kashida elongation in Arabic, stretched brackets in mathematics — must map to the character they represent, not to a sequence of repeated glyphs.

What a screen reader actually does

Arabic kashida is announced as a run of tatweel characters; a stretched brace is announced as a stack of fragments.

What the standard asks

PDF/UA-1 clause 7.2 deals with one typographic habit by name: characters that are drawn by assembling several glyphs into the appearance of one. Its examples are parentheses and brackets. Those must be tagged with /ActualText (ISO 32000-1, 14.9.4) giving the character they stand for.

The Matterhorn Protocol makes it one condition, 12-001, and marks it as needing a person. A checker sees glyphs; it cannot see that five of them are meant to be one brace.

What it looks like in the file

Typesetting systems build tall delimiters out of pieces. A left brace spanning four lines of a cases construction is an upper hook, a middle piece, a lower hook and as many extension pieces as the height needs. Unicode even encodes those pieces — U+23A7 to U+23AD for curly brackets, U+239B to U+23A0 for parentheses — so a font whose map uses them extracts the brace as ⎧ ⎪ ⎨ ⎪ ⎩. Mapped correctly, and still not a brace.

The repair is one /ActualText around the run of pieces, saying what they are:

/Span << /ActualText ({) >> BDC
  BT /F7 10 Tf
     1 0 0 1 72 640 Tm <..> Tj      % upper hook
     1 0 0 1 72 628 Tm <..> Tj      % extension
     1 0 0 1 72 616 Tm <..> Tj      % middle
     1 0 0 1 72 604 Tm <..> Tj      % extension
     1 0 0 1 72 592 Tm <..> Tj      % lower hook
  ET
EMC

The glyph codes depend on the font. /ActualText can also sit on a structure element instead of the marked content, when the pieces have a Span of their own.

Kashida: the same problem in running text

Arabic can justify a line by lengthening words instead of only widening the spaces between them — the lengthening stroke is called kashida. Some producers do it by inserting tatweel, U+0640, which is a real character. The word مطلوبة then extracts as مطلـــوبة: a search for the word does not find it, and a speech engine is handed a word with extra characters in it. Whether it skips them, names them or stumbles over the word depends on the engine.

The standard’s own example is brackets, and kashida is the same principle in running text: what is drawn stretched should read as the characters it stands for. /ActualText on the stretched word, giving it without the tatweel, does that.

Why this is a judgement

Because the same glyphs can mean two things. A run of brace pieces is one brace — unless the page is about TeX’s delimiter pieces. A tatweel is justification — unless someone typed it into a display heading on purpose, or the text is about the character. /ActualText placed on the wrong run deletes content as surely as it fixes it, and no checker can tell the cases apart. That is why 12-001 is decided by a person.

How to check it

1. Find the candidates. In mathematics: tall brackets and braces, matrices, radical signs over long expressions. In Arabic: fully justified paragraphs.
2. Copy and paste each candidate into a plain text editor. Bracket pieces paste as ⎧⎪⎨⎪⎩, ⎛⎜⎝, or nothing at all. Tatweel shows up as ـ inside words.
3. Look for /ActualText around them. Adobe’s documentation of the Tags panel and the Reading Order tool describes alternate text and does not describe ActualText, so Acrobat’s panels are not the documented way to see it. A free route that does work: qpdf --qdf --object-streams=disable in.pdf out.pdf writes the content streams uncompressed, so they can be read in a text editor — look for /ActualText in the BDC before the pieces, or on the structure element that holds them.
4. Decide. Stretching that is doing typographic work needs /ActualText. Characters that are there on purpose stay as they are.

How to fix it free

At the source, where possible. In pdfLaTeX, the accsupp package puts /ActualText around a piece of output; see LaTeX to accessible PDF for the tagging route as a whole. For Arabic, a justification setting that widens spaces instead of inserting kashida avoids the problem altogether — where the setting lives depends on the application.

In Acrobat, there is no documented step. Adobe’s Tags panel documentation covers alternate text, not ActualText. Alternate text is not a substitute here: PDF/UA asks for ActualText, and Adobe’s own Reading Order documentation notes that when alternate text is applied to a text element, the description is read instead of the text. (Adobe: Reading Order tool)

There is more on the difference between the two fields in ActualText in PDF, and on Arabic documents generally in Arabic PDF accessibility.

What Taggart does

Taggart has no check for this condition. It produces no finding, so 12-001 never appears among the findings or in the review queue. It is on the list of conditions Taggart asks a person to confirm before it will write the PDF/UA claim into the file. In the application the conformance card lists them, with one box to tick — I have checked these conditions by hand, or with another validator. Until someone has, the claim is not written. The confirmation covers the whole list at once, so make the check above before you give it.

Two things it does that touch the same material:

• Brace pieces from a font with no Unicode map and no exemption are reported as 10-001 and 31-027 — and as 17-003 when the document has a Formula. That is the mapping failing, not the stretching, but it brings the same glyphs to your attention.
• When Taggart repairs an Arabic line stored in visual order (TG-RTL-001), the /ActualText it writes is the line in logical order with tatweel removed and presentation forms folded back to plain letters — the word, not the stretch. It does this only for lines it is repairing for that reason. A logical-order line stretched with tatweel is left as it is and not reported.

How Taggart handles it

No software can decide this one, and Taggart has no check for it, so it never appears among the findings or in the review queue. It is on the list of conditions Taggart asks you to confirm by hand before it writes the PDF/UA claim into the file — the claim waits until you have.

Where this sits in the standards

Related conditions

• 10-001 Character code cannot be mapped to UnicodeA glyph is painted whose character code has no Unicode equivalent reachable through the font's ToUnicode CMap, encoding, or glyph names. The text renders correctly but cannot be extracted.
• 17-001 Content is a mathematical expression but is not tagged with a Formula tagAn equation is tagged as a paragraph or a figure rather than a Formula.
• TG-RTL-001 Right-to-left text is stored in visual orderOlder Israeli government, legal and DTP systems lay out Hebrew by reversing the character order and then rendering left-to-right. The page looks correct, but the stored text is backwards. Extracting it gives you the sentence mirrored, and the bidi algorithm then reverses it a second time.
• 13-008 ActualText not present when a Figure is intended to be consumed primarily as textA drop cap, a logo that is a word, an image of a signature block — content that is text — needs ActualText so it flows into the text stream.

Other conditions in checkpoint 12

Checkpoint 12 covers stretchable characters. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

This condition needs a person’s judgement, so there was nothing for a tool to check. Written from ISO 14289-1 and the Matterhorn Protocol on 2026-10-02. Last updated 2026-10-10.