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.
