How do we use SVG in our framework, ignoring compatibility issues
There is a convenient format for working with vector graphics on the web - SVG . If its full support by all browsers, it would have gained more popularity than it is now.
But we can actively use it in our Mozart framework, without looking at all compatibility issues. The point is that by means of the framework we can transcode one data stream into another. In the case of SVG, we transform it into a JPEG, GIF or PNG image format, which we give to the client (browser).
We do this using Java-based (like Mozart itself) Batik SVG Toolkit .
Let's look at an example. Recently we launched a site for a real estate agency, on which it was necessary to show a floor plan in the properties sold with colored apartment blocks. Different apartments had different colors, already purchased apartments should not be made out at all. A page where you can see an example: http://www.monarch-realty.ru/floor/81/774/154/145#content
')
At the entrance we have a floor scheme converted from a vector editor to SVG-format (almost any vector editor can do this). Each apartment has a substrate in the form of a closed polygon, which we can fill in (by default it is not filled), changing only the color in one place of the SVG file.
Using simple transformations (in Mozart, this can be done both via XSLT and at the API level via java, groovy or even javascript) when displaying each floor picture-scheme, we compare data from apartments in the database with an empty floor image, painting over needed blocks. Those. slightly convert the original SVG. Further, this SVG is transformed into an image that is cached and given to the client.
Everything happens dynamically, i.e. when data in the database is changed, the cache is reset, the image is redrawn at the first access.
This simple way we use the intended SVG, without looking at the complexity of format support in some browsers and other problems.
About Mozart you can read here: http://www.mozartframework.ru
UPD: I want to clarify the essence of such a decision. The following suggested options to use pure SVG and VML using solutions like raphaeljs.com.
Our source data was PDF and nothing else. It was necessary through vector editors to convert this data into SVG - each scheme was received as a huge number of vectors, so everything is drawn. All this was done by several MB. To transform all this into different formats, imposing also some kind of dynamics through JS - anguish for customers.
UPD2: as for Flash, of course, it is possible, but read the first UPD and take into account the need to have a flasher for such a solution ...
But we can actively use it in our Mozart framework, without looking at all compatibility issues. The point is that by means of the framework we can transcode one data stream into another. In the case of SVG, we transform it into a JPEG, GIF or PNG image format, which we give to the client (browser).
We do this using Java-based (like Mozart itself) Batik SVG Toolkit .
Let's look at an example. Recently we launched a site for a real estate agency, on which it was necessary to show a floor plan in the properties sold with colored apartment blocks. Different apartments had different colors, already purchased apartments should not be made out at all. A page where you can see an example: http://www.monarch-realty.ru/floor/81/774/154/145#content
')
At the entrance we have a floor scheme converted from a vector editor to SVG-format (almost any vector editor can do this). Each apartment has a substrate in the form of a closed polygon, which we can fill in (by default it is not filled), changing only the color in one place of the SVG file.
Using simple transformations (in Mozart, this can be done both via XSLT and at the API level via java, groovy or even javascript) when displaying each floor picture-scheme, we compare data from apartments in the database with an empty floor image, painting over needed blocks. Those. slightly convert the original SVG. Further, this SVG is transformed into an image that is cached and given to the client.
Everything happens dynamically, i.e. when data in the database is changed, the cache is reset, the image is redrawn at the first access.
This simple way we use the intended SVG, without looking at the complexity of format support in some browsers and other problems.
About Mozart you can read here: http://www.mozartframework.ru
UPD: I want to clarify the essence of such a decision. The following suggested options to use pure SVG and VML using solutions like raphaeljs.com.
Our source data was PDF and nothing else. It was necessary through vector editors to convert this data into SVG - each scheme was received as a huge number of vectors, so everything is drawn. All this was done by several MB. To transform all this into different formats, imposing also some kind of dynamics through JS - anguish for customers.
UPD2: as for Flash, of course, it is possible, but read the first UPD and take into account the need to have a flasher for such a solution ...
Source: https://habr.com/ru/post/91642/
All Articles