An all-zero FontBBox produces text chunks of zero height, and the text is then silently discarded

[SangWJDev]

Summary

TextChunksHelper.calculateTextBoundingBoxH() falls back to /FontBBox when the font descriptor has no /Ascent and no /Descent. When that FontBBox is [0 0 0 0], both ascent and descent become 0 and every text chunk of that font gets a height of exactly zero.

A font bounding box whose four elements are all zero carries no size information — it does not mean the glyphs have no size. Propagating it as a literal 0 produces a chunk that no consumer can distinguish from a glyph that genuinely has no extent.

Affected code

wcag-validation/src/main/java/org/verapdf/gf/model/factory/chunks/TextChunksHelper.java:

double[] fontBoundingBox = font.getBoundingBox();   // [0, 0, 0, 0]
Double descent = font.getDescent();                 // null - no /Descent
if (descent == null) {
    descent = fontBoundingBox[1];                   // -> 0.0
}
Double ascent = font.getAscent();                   // null - no /Ascent
if (ascent == null) {
    ascent = fontBoundingBox[3];                    // -> 0.0
}

Reproducing

repro-issueB-zero-fontbbox.pdf — 1.8 KB, hand-written, readable in a text editor. The generator script and both repro files are here; there are no third-party dependencies.

A single Type 3 font with the conventional /FontMatrix [0.001 0 0 0.001 0 0] and /Widths [500 500 500], so nothing unusual is going on with the font matrix. The only anomaly is:

/FontBBox        [ 0 0 0 0 ]
/FontDescriptor  << /Type /FontDescriptor /FontName /ReproType3B /Flags 32
                    /FontBBox [ 0 0 0 0 ] /ItalicAngle 0 /StemV 80 >>

— all-zero in both places, and no /Ascent, no /Descent. The content stream is a plain Tj with no kerning at all, so issue A cannot interfere.

Result, running the file through a veraPDF-based text consumer (opendataloader-pdf 2.x, which bundles veraPDF 1.31.99):

poppler (pdftotext) : ABC
veraPDF-based       : (empty file - 0 bytes, no exception, no warning, no log entry)

Impact

The chunk itself is produced; it just has height == 0. Consumers that filter by height then drop it. In opendataloader-pdf, TextProcessor.filterTinyText discards any chunk with height <= 1.0:

if (chunk.getBoundingBox().getHeight() <= 1.0) {
    list.set(i, null);
}

The document that led me here is a 156-page PowerPoint export in which all 156 embedded Type 3 fonts have /FontBBox [0 0 0 0] and no /Ascent or /Descent. It extracted 0 characters, and the run was reported as a success — no exception, no warning, nothing in the log. Everything needed to lay the text out is present in the file; it is read and then thrown away. (That document separately also hits #1623; the attached repro file does not, so it isolates this problem.)

I would argue the zero height is wrong regardless of what any particular downstream consumer does with it: a text chunk that reports zero height is stating something about the document that is not true.

Possible fix

Treat "no usable vertical metrics" as unknown rather than as zero, and fall back to a common em split:

if (ascent == 0.0 && descent == 0.0) {
    ascent = 0.8 / verticalScalingFactor;
    descent = -0.2 / verticalScalingFactor;
}

Dividing by the vertical scaling factor expresses the values in glyph space, so this holds for a Type 3 font with any FontMatrix as well as for ordinary fonts.

The exact constants are a proposal, not a claim. 0.8/−0.2 is a widely used default, but any reasonable pair works; the point is not to propagate a meaningless 0. If you would rather derive the extent from the d1 operands in the Type 3 CharProcs, or from /FontMatrix alone, or expose it as a setting, I am happy to rework the patch — I have no attachment to these numbers.

Fix

Proposed in veraPDF/veraPDF-validation#750

[SangWJDev]

Adding the exact wording from ISO 32000-1:2008. It turns out the spec states this explicitly, and — usefully for this report — it states it in the Type 3 font dictionary table rather than only in the generic font descriptor table, so it applies directly to the font in the attached file.

9.6.5, Type 3 Fonts, Table 112 — Entries in a Type 3 font dictionary, FontBBox:

(Required) A rectangle (see 7.9.5, "Rectangles") expressed in the glyph coordinate system, specifying the font bounding box. This is the smallest rectangle enclosing the shape that would result if all of the glyphs of the font were placed with their origins coincident and then filled.

If all four elements of the rectangle are zero, a conforming reader shall make no assumptions about glyph sizes based on the font bounding box. If any element is nonzero, the font bounding box shall be accurate. If any glyph's marks fall outside this bounding box, incorrect behavior may result.

That is a shall, and deriving an ascent and a descent of zero — and therefore a chunk height of zero — from [0 0 0 0] is exactly the assumption the sentence forbids.

In case the attached file looks malformed at first glance — it is not. The spec exempts Type 3 fonts from every single entry involved here:

entry	condition	where
/FontDescriptor	"(Required in Tagged PDF documents; shall be an indirect reference)" — optional otherwise	Table 112
/Ascent	"(Required, except for Type 3 fonts)"	Table 122
/Descent	"(Required, except for Type 3 fonts)"	Table 122
/FontBBox	"(Required, except for Type 3 fonts)"	Table 122

So a Type 3 font with no /Ascent, no /Descent, and a /FontBBox that carries no information is a fully conforming combination that a reader is obliged to cope with — the producer is not required to supply the metrics being fallen back on.

This does not settle which fallback values are right — that part of the patch is still just a proposal — but it does settle that propagating the zero is not an option.