I believe Matt's proposal would still keep w3c/epubcheck#1114 open. To quote that issue: SVG 1.1, per spec, relies on:

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

Because the svg11.dtd uses XML DTD modularization, it is full of entities. However, as Matt commented, those are forbidden by EPUB. As a consequence, EPUBCheck systematically refuses such SVG files, although they are perfectly valid per SVG Spec.

The problem with this illustrates Brady's comment:

Additionally, SVGs are rarely edited by hand, so content creators are at the mercy of graphics tools to generate documents

As a typical example, Adobe Illustrator systematically puts that DOCTYPE into a generated SVG files (or it did until the latest release, I did not check the last one).

This goes beyond SVG, mind you. MathML has the same problem afaik. I believe we may have to come back to the problem of how to handle XML entities.

B.t.w., the possible solution that came up w3c/epubcheck#1114 is to explicitly put exceptions to the entity rules concerning some standard DTD-s (that XML parsers are not really required to fetch anyway).

Validation of SVG #1323

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions