Comos Fill to SVG Path Fill.

Object in Comos can be color filled. It was not implemented in the previous engine. creating a filled path in comos creates a few additional lines in the CRP file compared to writing a normal line. The first step involve defining the path itself, the next step is assigning a line to a variable while the final one involve adding the line variable to the path itself. 

The code is written in such a way that the fill path is only drawn only after the current object is fully drawn. The reason for this is because there is no way on telling weather the last line has been added to the path. I dont think this code will play nice with arc element. 

Aside from the arc problem there is also the fact that in order for path fill to work in svg the path need to be continuos so for a triangle the line must be defined in such that point a to b, b to c and c to a. THe problem with crp is that isted of points the defined item are line so the three elements defiend wil be line ab, bc, ca. The code will only work if the line element is arrenged in such a manner, but it will get messed up if the element are defined differently ab, ca, bc or even ab cb ca. damnn. I can think of a solution but maybe later.

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].

ECC Graphical repersentation messup.

The other day, a member of the team requested for a unique representation of object that has been gone through ECC. At that time I decided it simply to use a feature that actually lies in connections that allow connection repersentation to be edited thorugh property manipulation. To do this the RI tab from pipe/connections are moved to a higher hierachy, hence affecting all the other object. To my amazement it does work as expected. The color of every object now can be manipulated through it’s property. A simple script has been witten to get all the object that has gone through ECC and all these item turned brown. Later it will be implemented onto the ecc object themselves so that this will be automated. 

This is very much a simpler approcah to revisioning, Comos does have it’s own internal revisioning engine, the only problem is that once it is turned on there will be limited control on the actual revisioning as it will be automated, all the little changes will be marked. The way these item are marked are less than favourable, no control over it. In the end if this feature is turned on the resulting document will look messy.

To me with our methodology on ECC, it was best to use the input from ECC to actually shoe these changes. It does work, now edited/ECCed item are colored brown an are clearly visible in each drawing.

But last week realised that the property seems to effect the whole graphical representation of each object in each drawing. So now everything is black, line thickness are fixed to 0.35. The worst part is that this happens as these documents are opened and saved. Since the it was like 3 weeks since I implement this. Most of the drawings now are pitch black. Seems like removing the proprerty from the base object doesn’t change anything. 

With this grave error I now realize what the first part of the gemotry function in the crp files error are refering to; the locally edited symbol, while the second one (used for svg) is the actual displayed item. The error seems to place the original symbol into the locally edited geometry function and placed a blackened, 0.35 thick symbols into the displayed area. To remedy things every symbol affected (which is all of them) has to be reset to default.

Damn!!