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