Repository navigation
Description
Reference.Type.SVG_CLIP_PATH is defined, is assigned to ids, and is handled
in the checker — but nothing ever creates a reference of that type, so the
branch that would use it is unreachable and clip-path references go
unvalidated.
Where the type appears (5.3.0)
| file | line | role |
|---|---|---|
references/Reference.java |
28 | the enum constant |
ops/OPSHandler.java |
211 | an SVG clipPath element's id is registered as this type |
references/ResourceReferencesChecker.java |
188 | case SVG_CLIP_PATH: — expects a reference of this type |
references/ResourceReferencesChecker.java |
279 | same, in the second switch |
There is no registerReference(..., Type.SVG_CLIP_PATH) anywhere in
src/main/java. checkPaint() (OPSHandler.java:68) is called only for
fill and stroke (lines 237–238), and a case-insensitive search for
clippath/clip-path across src/main/java returns exactly one hit — the
id-typing at line 209. Nothing reads the attribute.
So clipPath is typed as a target only, and the two case SVG_CLIP_PATH
branches cannot be reached.
Effect
Two things go unreported. Both books below are a minimal EPUB 3 with one
XHTML document containing inline SVG; checked with epubcheck -u, 5.3.0.
- A clip-path reference whose target is not a
clipPath:
<svg xmlns="http://www.w3.org/2000/svg">
<defs><linearGradient id="grad"><stop offset="0"/></linearGradient></defs>
<rect clip-path="url(#grad)" width="5" height="5"/>
</svg>→ no message. The equivalent mismatch through fill (fill="url(#sym)"
pointing at a <symbol>) is reported as RSC-014, so the intent seems to be
that this one would be too.
- A clip-path reference to an id that does not exist:
<svg xmlns="http://www.w3.org/2000/svg">
<defs><clipPath id="cp"><rect width="5" height="5"/></clipPath></defs>
<rect clip-path="url(#nope)" width="5" height="5"/>
</svg>→ no message. A dangling fill="url(#nope)" is RSC-012 in the same document.
(The CSS side does not cover it either: a stylesheet carrying
.a { clip-path: url(#nope) } is likewise silent.)
Not sure which fix you want
Registering clip-path in checkPaint-style would make both cases behave
like the paint ones. Alternatively, if clip-path references are deliberately
out of scope, the two case SVG_CLIP_PATH branches and the id-typing at
OPSHandler.java:211 are dead and could be removed.
Reported from work on an independent validator; happy to supply the sample
EPUBs if useful.
Activity
rdeltour commentedon Sep 14, 2026
Thanks for the report!
You are correct that
clip-pathshould not be treated differently than paint attributes (strokeandfill). This is fixed in #1718.Note that some of the fragment-related checks (
RSC-013,RSC-014, andRSC-015) come from legacy code, and I do not think they are very robust. It is also not specifically required by EPUB, and slightly out of scope for EPUBCheck. So the PR also downgrades these to USAGE.feat: downgrade advanced URL fragment integrity checks to USAGE
Catch up with epubcheck 5.4.0