# Specify an SVG encoding algorithm?

This recursive function definition creates a number series that I'm interested in:

f[y_][x_] := f[y][x] = Mod[10 f[y][x - 1], y];
f[y_][1] = 1


When applying it to any one of certain prime numbers n, it returns a series related to the repeating decimal expansions of k/n with k $\epsilon$ {1..n-1}. For example, with n = 97,

In[]:= series97 = f[97][#] & /@ Range[1, 96]

Out[]= {1, 10, 3, 30, 9, 90, 27, 76, 81, 34, 49, 5, 50, 15, 53, 45, \
62, 38, 89, 17, 73, 51, 25, 56, 75, 71, 31, 19, 93, 57, 85, 74, \
61, 28, 86, 84, 64, 58, 95, 77, 91, 37, 79, 14, 43, 42, 32, 29, \
96, 87, 94, 67, 88, 7, 70, 21, 16, 63, 48, 92, 47, 82, 44, 52, \
35, 59, 8, 80, 24, 46, 72, 41, 22, 26, 66, 78, 4, 40, 12, 23, 36, \
69, 11, 13, 33, 39, 2, 20, 6, 60, 18, 83, 54, 55, 65, 68}


I am looking at the polygons that result from mapping these numbers onto CirclePoints, as follows:

Graphics[Polygon[CirclePoints[97][[#]] & /@ series97]]


In short, a mathematically-derived figure which ought to be a tailor-made case for using SVG encoding when exported. However, while the .jpg output looks like this:

The SVG ends up a bit splotchy (I've uploaded a screenshot here, of course):

How can I get the second image to look like the first, while retaining the vector information implicit in the way the graphics were generated? If I've understood SVG correctly, this should (1) save memory and (2) give me something arbitrarily zoomable.... please do correct me if I'm wrong.

• I can reproduce the problem. You can work around this bug by using my answer to Exporting Mathematica expression as SVG
– Jens
Sep 4, 2018 at 19:54
• Do you think I should report it as a bug? Sep 4, 2018 at 22:34
• Yes, it's worth reporting as a bug - maybe they'll give you a rational explanation, but I don't have one, and it's certainly not the expected behavior.
– Jens
Sep 5, 2018 at 0:02
• Perhaps related: Getting EPS imports to respect the original fill rule
– Jens
Sep 5, 2018 at 0:12