The svg spec says that renderers should support values within the range of a C float (https://www.w3.org/TR/SVG/types.html#Precision). However, in practice, inkscape appears to be limited to overflow around 2**24, probably due to the fact that it relies on cairo (which has the same limitation) for rendering. Chromium's svg renderer also appears to hit an overflow somewhere (not sure about the exact value). Agg also has this limitation (see comment at the top of_path_converters.h:

PathClipper: Clips line segments to a given rectangle. This is
helpful for data reduction, and also to avoid a limitation in
Agg where coordinates can not be larger than 24-bit signed
integers.

and it is explicitly tested that this is worked around for Agg (test_simplification.test_overflow).

Currently, the svg backend clips output paths to the actually drawn canvas, but does not clip filled areas. So, with

from pylab import *fill_between([0, 1e10], [1, 1], color="b")plot([0, 1e10], [.5, .5], "r")gca().set(xlim=(0, 1))  # force very large x-coordinates in pixelsgca().set_axis_off()savefig("/tmp/foo.png")savefig("/tmp/foo.svg")

we get:

png:

svg, converted to png by inkscape (can't attach a svg in a gh comment) -- but chromium renders the same way:

(the red line is drawn accurately because it is clipped in the SVG output; the blue box disappears because it is not clipped and overflows inkscape's renderer)

There are similar overflow issues with pdf output (via ghostscript -- the relevant renderer, as we use it for the test suite), which are in fact the factor limiting the clip value in#9477 (that's how I found out about this issue), although I can't point to anything in the pdf spec right now.

Now one may argue that "this is the fault of the noncompliant renderer", but given that we arealready clipping unfilled paths, and also fully working around this for raster output, I think it makes sense to clip filled paths as well in svg (and pdf). (Of course, this will still fail when someone tries to make a svg image with a dimension exceeding 2**24. Honestly I don't care about that case :-))

Related to#8901 (clipping in eps).