Seems like I cracked it! Sign Up | LinkedIn
Update to v1.0.0 coming soon.
waseigo
waseigo
@ku1ik, this has been a crazy nerd-snipe… crazy fun too!
As it turns out, identifying groups of rectangles is fine – I cracked it elegantly by using Enum.reduce and Enum.reduce_until. See the PolygonReducer module.
The problem is the consequent conversion of the edges of those groups into paths, when the groups are topologically “donuts” with one or more “holes” within them.
In such cases, the outer list of edges is disjoint with the list of inner edges, which itself might contain disjoint “islands” of edge lists.
I’m in way over my head, and think that the simplest approach is this one:
- Maintain the list of
<rect>tags, but put them into a<g>node, which will style all of them at once. - Add a background rectangle covering the canvas.
- Create a mask with the same content as the group of rectangles, to excise the foreground from the background rectangle.
Something like this: [identicon_svg - SVG Viewer]
Admittedly, this doesn’t save any space, but given that most web servers are likely to have gzip enabled, and also given the highly-compressible duplication of the rectangles, it would get the job done – with padding, and maintaining the ability to set the ability of the overall graphic to the same value without bg_color affecting the color of the foreground.
In fact, the example SVG linked to above is 1488 bytes long, but only 403 bytes long gzipped.
So, I think I’ll call it quits on solving this, and will approach this as in the list above.
1
ku1ik
Compared to v0.8? How so? Using single background rect (in my PR) reduced the size by almost 50%, and you mentioned you’ll do this in your impl too. So, is there extra overhead somewhere else which reduces the overall win? I guess read it wrong 
0
waseigo
There’s overhead because the foreground group of rectangles needs to be duplicated in the file; the first time, it’s the foreground. The second time, it’s to define a cut-out mask.
0
waseigo
I had an idea yesterday though, so I’m not giving up yet.
For every “polygon” (a grouping of rectangles), first remove the duplicate edges – those are the internal ones.
What’s left is a list of edges that may contain disjoint sublist of edges. For example, on the image shown here, each polygon’s edgelist is made up of the edges of the outer boundary and of the inner “hole” boundary. It’s possible (actually verified through randomization) that a polygon has more than one “holes”.
So, for each polygon, I’m now coding each edge in a way that’s direction independent, so that I don’t have to check coordinates of the edge’s vertices to determine connectivity. Then, I intend to utilize the exact same approach as in PolygonReducer to split the edgelist of a polygon into sublists.
I’ve already written code that finds the shortest edge-distance between two such sublists, then builds a bi-directional “bridge” of edges so that they can be connected. It needs tweaking to ensure that the traversal direction is consistent, so that I don’t make a “figure 8” out of the outer edges and the hole edges.
Basically, computational geometry “from LIDL”, as we say in Greece… 
1
waseigo
Oh yeah, I forgot to say – v0.7.0 was too simplistic. Already taking the styling out of every single rect and putting it on a <g> with that styling already saves a lot of space.
0
ku1ik
I saw you released v0.8. It’s without the padding support, correct? Does the latest version in master branch support padding? I guess I could point mix directly to the repo then.
0
waseigo
waseigo