1) If we have some problem when parsing and displaying the SVG file. We can improve the parser or tell the developer how to work around it. But if we choose to abandon the cross-platform feature, developers can do nothing if they want to use the SVG map on other platforms like WeChat and NodeJS
2) SVG data in this case is a data source like GeoJSON, not a rendering method. So I think echarts should handle the SVG file consistently all platforms. SHUANG SU <[email protected]> 于2018年5月5日周六 下午7:59写道： > typo: "resolution" -> "solution", stupid mistake :) > > > ------------------------------ > Su Shuang (100pah) > ------------------------------ > > > 2018-05-05 19:58 GMT+08:00 SHUANG SU <[email protected]>: > > > > > (1) > > > About the complexity, we've tried it in ECharts 2. I think it's not > that > > > complex and it works fine to me. > > > > The SVG parser in ECharts2 only supports "convert certain SVG to zrender > > shape". > > I've tested some of the SVG files downloaded from the web on ECharts2 SVG > > parser. > > Some of them cannot be rendered correctly. > > For example: > > https://upload.wikimedia.org/wikipedia/commons/9/98/Santorini-topo.svg > > https://upload.wikimedia.org/wikipedia/commons/3/3a/Tehran_topo.svg > > > > If we use a "simple SVG parser" like ECharts2 did, we probably have to > > make some rules or restrictions about: > > "if the SVG file can be parsed and rendered correctly, it should be like > > this xxx, and should not contain xxx". > > but I think it is difficult for developers or designers to make an SVG > > file following the rules or restrictions. > > > > If we implement a "complete SVG parse", be able to parse any SVG file > > against the SVG specification, > > I am afraid it is probably a difficult job (?) and brings lots of code. > > If we can do that, we are actually implementing a SVG renderer, which > > seems should not be the job of > > ECharts, but the job of browsers. > > > > > > (2) > > > Render SVG directly into HTML is not friendly to other platforms. > > > > For the feature "getDataURL", I think it might be resolved by some trick. > > For headless rendering, generally, I think there is rarely scenario that > > using SVG in a > > headless environment that not support SVG. If so, it seems not the job of > > ECharts to > > give the resolution of "rendering an SVG on a headless environment that > > not support SVG". > > > > (3) > > About the user interaction, it is actually another topic. We can discuss > > them soon in another thread. > > > > > > > > > > > > > > > > > > > > ------------------------------ > > Su Shuang (100pah) > > ------------------------------ > > > > > > 2018-05-04 17:08 GMT+08:00 沈毅 <[email protected]>: > > > >> Render SVG directly into HTML is not friendly to other platforms. > >> Cross-platform is always important when we choose the solution. That's > >> also > >> what we considered when implementing the rich text label. > >> > >> I can't get your concern about determining which shapes are needed to be > >> user > >> interactive. It's more about how we designing the interface. I don't > think > >> it's relative to the underlying implementation. > >> > >> About the complexity, we've tried it in ECharts 2. I think it's not that > >> complex and it works fine to me. > >> > >> SHUANG SU <[email protected]> 于2018年5月4日周五 下午3:18写道： > >> > >> > But I doubt that parse an SVG file is probably a heavy workload if we > >> > implement a complete (not rough) parser. (?) > >> > > >> > And it probably difficult to determine which shapes are needed to be > >> user > >> > interactive if the SVG is very complicated. > >> > (for example, highlight when hovering). > >> > > >> > So I think could we render the SVG directly into HTML document? > >> > Meanwhile, if user interaction is required, the designer can provide a > >> > separate SVG file, which including only <path> elements, > >> > to specify all of the <path>s that are needed to be interactive. > >> > > >> > (This idea comes from Dingding, and TianYu agrees that). > >> > > >> > > >> > > >> > > >> > ------------------------------ > >> > Su Shuang (100pah) > >> > ------------------------------ > >> > > >> > > >> > 2018-05-04 12:34 GMT+08:00 沈毅 <[email protected]>: > >> > > >> > > Use SVG directly means parse SVG file and rendered it with Canvas? I > >> > think > >> > > it's better because it can be resolution independent. Also we can > >> change > >> > > the style of each element to encode the data. > >> > > > >> > > > >> > > SHUANG SU <[email protected]> 于2018年5月2日周三 下午2:29写道： > >> > > > >> > > > Shen Yi, > >> > > > > >> > > > Using image as geo background, will cause distortion when zooming. > >> > > > May be, it is a better way to use SVG directly on the browser > (make > >> a > >> > > > zrender/graphic/SVGImage) ? > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > ------------------------------ > >> > > > Su Shuang (100pah) > >> > > > ------------------------------ > >> > > > > >> > > > > >> > > > 2018-04-30 2:45 GMT+08:00 SHUANG SU <[email protected]>: > >> > > > > >> > > > > > >> > > > > (1) > >> > > > > > And if background image > >> > > > > > has SVG image source, will the node information in SVG been > >> parsed > >> > > and > >> > > > > > displayed? > >> > > > > > >> > > > > Does the simple way appropriate? > >> > > > > ```js > >> > > > > var img = new Image() > >> > > > > img.src = 'some.svg'; > >> > > > > // drawImage to canvas. > >> > > > > ``` > >> > > > > > >> > > > > There might be some compatible issue for old browser ( > >> > > > > https://caniuse.com/#feat=svg-img) in this way, > >> > > > > but I think it might bring complexity if imclude SVG parsing > code > >> to > >> > > > > echarts, > >> > > > > and not necessary if not need to interact with the inner shape > of > >> a > >> > > SVG. > >> > > > > > >> > > > > > >> > > > > (2) > >> > > > > > Are background and backgroundCoord general properties for the > >> geo > >> > > > > > component? Can they be used with mapType property > >> > > > > > >> > > > > I think that both the `background` and `mapType` can be > specified > >> on > >> > > > > option. > >> > > > > The view rect can be calculated by union the `backgroundCoord: > >> {x, y, > >> > > > > width, height}` > >> > > > > and the GeoJSON (specified by `mayType`, if the user needs it). > >> > > > > > >> > > > > But for this part, consider a scenario: > >> > > > > The background is a shopping mall map, and the user might need > >> some > >> > > > > polygons > >> > > > > to describe some area (which can be interactive, like, highlight > >> when > >> > > > > hovering). > >> > > > > If the polygons are described using GeoJSON, the option should > be: > >> > > > > > >> > > > > ```js > >> > > > > echarts.registerMap('mall', thePolygonsGeoJSON); > >> > > > > > >> > > > > var option = { > >> > > > > geo: { > >> > > > > background: 'mall.png', > >> > > > > backgroundCoord: {x: 0, y: 0, width: 1000, height: 600}, > >> > > > > mapType: 'mall' > >> > > > > } > >> > > > > } > >> > > > > ``` > >> > > > > > >> > > > > where the GeoJSON 'mall' and background image 'mall.png' are > >> > specified > >> > > in > >> > > > > different styles. > >> > > > > Is it a little strange? > >> > > > > > >> > > > > Or, another approach: > >> > > > > the users can describe the polygons not in GeoJSON (since it is > a > >> > > little > >> > > > > difficult to make > >> > > > > GeoJSON), but using a custom series, or a series type 'polygon' > >> (or > >> > > > > 'lines', that already exists). > >> > > > > > >> > > > > ```js > >> > > > > var option = { > >> > > > > geo: { > >> > > > > background: 'mall.png', > >> > > > > backgroundCoord: {x: 0, y: 0, width: 1000, height: > >> 600}, > >> > > > > }, > >> > > > > series: [{ > >> > > > > type: 'polygon', // or type: 'lines' > >> > > > > data: [ > >> > > > > // points of a polygon > >> > > > > [[px0,py0], [px1,py1], ...], > >> > > > > // Or even a SVGPath ? (which is more > convenient > >> for > >> > > > > designers?) > >> > > > > 'path://M164,210.677v33.47l154 > >> .656,66.356L468,243z', > >> > > > > ... > >> > > > > ] > >> > > > > }] > >> > > > > }; > >> > > > > > >> > > > > Is it appropriate? > >> > > > > I am thinking that how to make it easier for designers to > convert > >> the > >> > > SVG > >> > > > > or Adobe Illustrator path to the input of the echarts. > >> > > > > In echarts 2, special tag needed to be markd on a SVG shape if > it > >> is > >> > > > > needed to be parsed and be interactive in echarts. > >> > > > > But adding special tags is not convenient I think. > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > ------------------------------ > >> > > > > Su Shuang (100pah) > >> > > > > ------------------------------ > >> > > > > > >> > > > > > >> > > > > > >> > > > > 2018-04-29 23:57 GMT+08:00 沈毅 <[email protected]>: > >> > > > > > >> > > > >> Some questions. > >> > > > >> > >> > > > >> Are background and backgroundCoord general properties for the > geo > >> > > > >> component? Can they be used with mapType property? And if > >> background > >> > > > image > >> > > > >> has SVG image source, will the node information in SVG been > >> parsed > >> > and > >> > > > >> displayed? > >> > > > >> > >> > > > >> SHUANG SU <[email protected]> 于2018年4月29日周日 上午12:29写道： > >> > > > >> > >> > > > >> > Pissang and All, > >> > > > >> > > >> > > > >> > > >> > > > >> > Currently, geo coordinate system only supports GeoJson, which > >> is > >> > not > >> > > > >> > convenient in some scenario that the base map might be the > >> > shopping > >> > > > mall > >> > > > >> > map, airport map, airplane seat map, topographic map, etc., > >> where > >> > > > using > >> > > > >> > image or SVG is an easy and conventional way. > >> > > > >> > > >> > > > >> > So, should we provide "echarts option" like the snippet below > >> for > >> > > this > >> > > > >> > feature? > >> > > > >> > > >> > > > >> > > >> > > > >> > ```js > >> > > > >> > var option = { > >> > > > >> > geo: { > >> > > > >> > > >> > > > >> > // Use as background image, which can be zoomed and > >> moving > >> > > in > >> > > > >> the > >> > > > >> > geo coordSys. > >> > > > >> > background: 'shopping-mall.png', // or > >> 'shopping-mall.svg' > >> > > > >> > > >> > > > >> > // Specify how the background is located in this geo. > >> > > > >> > // Essentially the value is geo coords of the > >> background > >> > > rect. > >> > > > >> > the image width/height, where the geo > >> > > > >> > backgroundCoord: { > >> > > > >> > x: 0, > >> > > > >> > y: 0, > >> > > > >> > // Conventionally, we can use the image size as > the > >> > geo > >> > > > >> coords > >> > > > >> > here. > >> > > > >> > width: 1000, > >> > > > >> > height: 600 > >> > > > >> > }, > >> > > > >> > > >> > > > >> > // In this case, we do not need to provide a GeoJSON > >> and > >> > > > spcify > >> > > > >> > "mapType" here. > >> > > > >> > > >> > > > >> > }, > >> > > > >> > ... > >> > > > >> > }; > >> > > > >> > ``` > >> > > > >> > > >> > > > >> > In fact, this feature (using a roamable background image on > >> geo) > >> > can > >> > > > be > >> > > > >> > implemented > >> > > > >> > by the "custom series", but it is not convenient (after all, > it > >> > > > require > >> > > > >> > users to provide a GeoJSON to specify the bounding rect). > >> > > > >> > > >> > > > >> > Or any other ideas? > >> > > > >> > > >> > > > >> > > >> > > > >> > ---------------------------- > >> > > > >> > Su Shuang (100pah) > >> > > > >> > ---------------------------- > >> > > > >> > > >> > > > >> > >> > > > >> > >> > > > >> -- > >> > > > >> Yi Shen > >> > > > >> Senior Developer > >> > > > >> Baidu, Inc. > >> > > > >> > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > -- > >> > > Yi Shen > >> > > Senior Developer > >> > > Baidu, Inc. > >> > > > >> > > >> > >> > >> -- > >> Yi Shen > >> Senior Developer > >> Baidu, Inc. > >> > > > > > -- Yi Shen Senior Developer Baidu, Inc.
