[PATCH][CLA] VML Renderer generates invalid path definitions during fill settings on closed path

[Jared Jurkiewicz]

The VML renderer seems to generate bogus path definitions for the GFX shape Path. This becomes apparent when you use the utils.serialize(surface) API on a VML-drawn area. You end up getting a Path like:

}, {

"shape": {

"type": "path", "path": "M 342 150L 342 38A 112 112 0 0 1 453.3865 161.7072L 342 150ZM 342 150L 342 38A 112 112 0 0 1 453.3865 161.7072L 342 150ZM 342 150L 342 38A 112 112 0 0 1 453.3865 161.7072L 342 150ZM 342 150L 342 38A 112 112 0 0 1 453.3865 161.7072L 342 150ZM 342 150L 342 38A 112 112 0 0 1 453.3865 161.7072L 342 150ZM 342 150L 342 38A 112 112 0 0 1 453.3865 161.7072L 342 150ZM 342 150L 342 38A 112 112 0 0 1 453.3865 161.7072L 342 150ZM 342 150L 342 38A 112 112 0 0 1 453.3865 161.7072L 342 150Z"

}, "stroke": {

"type": "stroke", "color": {

"b": 0, "g": 0, "r": 153

}, "style": "solid", "width": 1, "cap": "butt", "join": 4

}, "fill": {

"type": "linear", "x1": 342, "y1": 38, "x2": 342, "y2": 161.7071878859772, "colors": [{

"offset": 0, "color": "#d93838"

}, {

"offset": 1, "color": "#990000"

}]

}

}, {

Notice that the path: value seems to have a repeating value in it. Basically, it duplicates the path N times (where N is the number of times setFill is called after the path is created). What happens is basically this:

gfx/vml.setFill -> gfx/path._getRealBBox -> gfx/path.updateWithSegment -> Updates shape by re-interating over th segments again and adding them a second time, which duplicates the path data into the GFX shape object.

I've worked around this by tweaking gfx/vml to have its vml.Path define its own _getRealBBox() that does this:

_getRealBBox: function(){

summary: returns an array of four points or null This is called by setFill, which actually creates the path, so we want to avoid duping the path repeatedly in the shape by clearing the path before re-add. this._confirmSegmented(); if(this.tbbox){

return this.tbbox; Array

} if(typeof this.shape.path == "string"){

this.shape.path = "";

} return this.inherited(arguments);

}

And that seems to work.

Additionally, I found cases where doing toSvg() on the VML surface would generate stroke-opacity="undefined" in the SVG. This is invalid. I tweaked the toSvg() api to also remove those (and let it default to 1, as per SVG spec).

If there are better ways to fix this, I would love to know. But as it stands this is how I've figured out how to fix the issues.

[Jared Jurkiewicz]

Possible solution for this issue.

[Jared Jurkiewicz]

​https://github.com/dojo/dojox/pull/127

[Jared Jurkiewicz]

Merged in: ​https://github.com/dojo/dojox/commit/cacc09e1bacb0f78eeab56ff5c32089a27298011

[Colin Snover]

If this is a defect could you please backport? Thank you.

[Jared Jurkiewicz <[email protected]…>]

In 99ad45340f02b09b95d0b6a17c91e6c72fc674bc/dojox:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Jared Jurkiewicz <[email protected]…>]

In 25e0aada06ea9fbf9ce9e6f41d630c4eb9fe91bd/dojox:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Jared Jurkiewicz <[email protected]…>]

In d73338e0700a1704c1ee670c2daa28f45b6c8255/dojox:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Jared Jurkiewicz <[email protected]…>]

In 9e9aaf1a56eb8b8a12d78bdeb448e73a60036a82/dojox:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[Jared Jurkiewicz]

Backported to 1.10, 1.9, 1.8, 1.7.

[Colin Snover]

Thanks!