PDF/UA-1 rule 7.21.3.3-2: WMode entry in the embedded CMap and in the CMap dictionary are not identical

Not fixed automatically font

What veraPDF reports

WMode entry (value %1) in the embedded CMap and in the CMap dictionary (value %2) are not identical

veraPDF rule 7.21.3.3-2 = ISO 14289-1:2014 clause 7.21.3.3, test 2, checked on PDF object CMapFile.

What the requirement says

For those CMaps that are embedded, the integer value of the WMode entry in the CMap dictionary shall be identical to the WMode value in the embedded CMap stream

Can it be fixed automatically?

Not fixed automatically. This failure needs the authoring tool or manual remediation; the automatic fix does not change it.

How to fix it by hand

Fonts are fixed at the source: export the PDF again from the authoring application with all fonts embedded (most office tools have an “embed fonts” or PDF/A option), or use a preflight tool that embeds missing fonts. Editing the PDF metadata does not change fonts.

Check your PDF now (free)

Upload the PDF: veraPDF lists every failed PDF/UA-1 rule, our fix runs, and veraPDF checks the fixed file again — you see “N failed rules before → M after” before deciding. The fixed file costs 19 € (excl. VAT); the check is free. We never call a file “accessible” or “compliant”.

Other rules in clause 7.21.3.3

7.21.3.3-1 All CMaps used within a PDF/UA file, except those listed in ISO 32000-1:2008, 9.7.5.2, Table 118, shall be embedded in t
7.21.3.3-3 A CMap shall not reference any other CMap except those listed in ISO 32000-1:2008, 9.7.5.2, Table 118

Rule text (description and error message): veraPDF validation profile PDF/UA-1 © veraPDF Consortium, licensed under CC BY 4.0. This site is not affiliated with the veraPDF Consortium, the PDF Association, ISO or Adobe. Adobe and Acrobat are trademarks of Adobe; the Acrobat checker item is named only to help you match the two reports.