Svg creation optimization, XMLdom from flatfile.

The reason why it was written flatfilely because it was easy to begin with, but as the code grew it seems problematic. The fact that elements are written all over the place, ugly. It seems that using XMLdom was way much eassier that I’ve anticipated, damnn. One note though it seems that getElementById doesnt work, supposably I need to use nodeFromId; never managed to get it to work as well, double damnn. 

Funnyly enough there seems to be no performace gain from flatfile to xmldom. It was another reason for the jump to XMLdom. But I do get a cleaner code. A few optimazation were also done to cut down the size of the svg file in this process. the obvious one to round all the number to the nearest 1/10.  Better use of CSS to further cuts repetitive usage of fill, stroke on the same value. The use tag now held fewer attributes, most of the trigger are added by javascript on load. 

But the most significant optimization actually came from optimizing the pipe representation (done in comos). I’ve realised this for quite some time, but never done anything about it. In comos every unique pipe can be added. A single tile of the pipe is drawn for reference inside the system, the way this pipe representation made into the final drawing is that it bacame a repetative tile. Most of the tile are 2 units in length, so for a pipe of length 1000 units, there will be 500 tiles of the same pipe, brutely effective in execution but this ends up strining any machnine that displaying it’s drawing. So I’ve increased the tile size to 5 units, and most of the drawings now are hald their original sizes. The better way of doing this would be using some stroke template for pipes (not sure if svg do this, something like the pattern fill)

Alongside that code are also updated so that line thickness and color are accounted for both object and free line. On top of that filled item in Comos are now filled inside the SVG as well [different post].