Am working on a project where complicated visuals are generated on a server in svg to be rendered on a browser. One problem I'm having involves text layout.
In some cases, I dynamically generate some text in an svg text element, but need to know what the size it will be when rendered.
There are some other stack overflow questions that are somewhat similar:
Measuring dimensions of svg elements in Angular
Measure SVG text dimensions without rendering
The difference here, though, is that those are done in the web browser, I'm trying to do this on the server, specifically in a .NET Core application running in a docker container, which would ideally provide only a minimal environment.
Thanks so much for help in advance.
Related
I am looking for the best approach for generating images of text on the server side (preferably Node.js). It will need to accommodate things like paging (so generating multiple images of text for one text input if it is too long to fit on one page). I am looking for something that is fairly precise and allows for a good deal of type configuration.
I have looked at a few options:
Use Canvas. This approach would work for most of the use cases. I could use a text engine like textjs for the layout. However, this is somewhat limiting as Canvas doesn't have specific text metrics (for things like text height used for exact positioning). This could make paging difficult.
Use normal HTML with something like PhantomJS to generate and them capture an image of the text. While this approach will work for some use cases, it makes it hard to handle things like paging.
Use some other text engine. I've looked around and found some options - but it would need to be something that I could call from Nodejs (as I'll likely use this on AWS Lambda).
What would you recommend?
I lately did something very similar - also with node.js on Lambda. In my opinion the best approach is using PhantomJS and maybe taking the detour of generating a PDF.
With HTML and CSS you can conveniently style the output exactly how you want it, which is a great advantage about the way more complicated Canvas approach. You only have to take care of adding some horizontal space wherever you expect the pagebreak (of course this depends on your usecase and may not be necessary). Having the rendered HTML page you now have two options:
You could generate a PDF - which will take care of generating multiple pages - and then rasterize that to images
Or you directly generate an image with Screen Capture (example Code) and then splitt that image horizontally
Both approaches worked fine for me.
I have to draw charts on browser using a python backend (which may not matter here). There are numerous libraries like JQPlot, D3, Google Charts for achieving this.
But if you classify them, they are either HTML5 Canvas based or SVG based. Both are important technologies in their own space. But
for charting as a subject, shall I go with SVG based libraries or
HTML5 Canvas based libraries. What are downside and benefits of
both approaches.
I don't have any prior experience with charting and don't want to hit the wall
after I start the project.
Projects with a large amount of data may favor canvas. SVG approaches typically create a DOM node per point (unless you make paths), which can lead to:
An explosion in the size of your DOM tree
Performance problems
Using a path, you can get around this problem, but then you lose interactivity.
Say you're building a stock chart. If you are talking about a chart with, say... max 5 years and end of trade data samples only, I think the answer is clearly SVG. If you're talking about looking at Walmart's historical data from day one of trading or doing full trade information per minute, you are going to have to really look carefully at SVG. Probably will have to employ fancy memory management and a fetch-on-demand approach as SVG will fall apart, particularly if you go one sample to one SVG node.
If interactivity is a requirement, SVG easily has the edge, given:
It is a retained mode API
You can use typical event handlers
You can add/remove nodes easily, etc.
Of course, you see that if you require full interactivity, it may go against mechanisms that allow SVG to scale, like path collapsing, so there is an inherent tension here.
There is going to be a trade-off in extremes. If size is small, the answer is SVG hands-down. If size is large and no interactivity, the answer is SVG with path drawing only or using Canvas. If size is large and interactivity is required, you have to go canvas or tricky SVG, which is complex in either case.
Some libraries out there offer both canvas and SVG renders, such as ZingChart and Dojo. Others tend to stick with just one of the two options.
Being vector based, SVG gets you scalability for free, and a side effect of this is that it's sharp on high resolution displays and sharp when printed. You can kind of get around this with canvas by rendering at 2x resolution and scaling your canvas but it's kind of a half-solution.
SVG I think is the modern way and the way to do this moving forward.
If you are concerned about rendering speed if you have many nodes consider also that if you're using canvas, you're basically using your own Javascript based rendering code which has to render those same nodes. You do get the predictability of only having to render it once, but if you only render it once that also means you lose the ability to re-render when zooming or to do various interactive things. If performance is a problem you can simplify SVG by sub-sampling your data, taking moving averages and plotting that only once per x rows, etc depending on what you're doing. But, we're talking thousands and thousands of nodes with almost no impact.
Canvas still has a place if you are building a web based raster graphics editor or something that in inherently raster-based but essentially if we are looking at charts, we're talking about something that's inherently vector based.
I'm looking at some older code which is rendering some images, animations, etc... for a website by generating a web page containing significant SVG elements. The result is a fairly complicated, interactive, interface. I've been tasked with migrating the application to instead generate WebGL calls.
This is a non-trivial task, considering all of the niceties that come with SVG, which are not directly available if going straight to a WebGL implementation. I've been debating whether I should pitch migrating to using something like Three.js instead, but don't know enough about the available options to make a good decision.
What are some reasonable options I should consider when trying to build my battle plan here?
I would suggest you look at http://code.google.com/p/canvg/ as an option.
I assume it is using getContext("2d") not getContext("experimental-webgl") or getContext("webgl").
WebGL provides a 3d interface and I am not sure if there is any advantage to using it for 2d graphics, since you don't have any 3d transforms for the GPU to work on. If they are interested in Canvas not specifically webgl ... Canvg would bring over some of the niceties of SVG which would be the source content.
If the issue is lack of support for SVG in browsers http://code.google.com/p/svgweb/ goes a long way to solving that problem.
Are SVG graphics a viable option for an in-browser game, with a google-maps style interface? This would involve zooming in/out, and scrolling in two dimensions over a very large distance.
For example, the client might request some area to be drawn in from the server -- and rather than the server returning a generated image for that section, it would return a series of gzipped SVG images and their locations in the requested area. Then the user could zoom in and out without grabbing new "tiles" from the server, since SVGs are scalable.
Would this be better than generating pngs or jpegs and sending back tiles? Would it perform well if there were many clients requesting images all over the place? Would it perform well on the client? What are the downsides to this approach?
In my experienced. The downside is the achievable level of detail using SVG is lower than lossy image compression like jpeg and png. I had difficulties getting all my vector graphics to play nicely with each other. If your artists are comfortable with working in SVG then this may not be an issue. Another note is that SVG compatibility may very between browsers. For instance I'm not sure which browsers support SVG. Webkit does, and I think Firefox does mostly, but I'm fairly sure IE is out of the picture, so to speak.
Overall SVG will put higher demands on client machines and lower demands on your servers. Calculating hundreds of SVG images is a lot more work than arranging PNGs.
In really depends on your game. If you are writing Chess, it would probably work fine. If you want to do something more complex in real time( E.G. a 2d side scrolling game), I have no clue.
using this SVG clock in Raephael as an Example. I am running Chrome on Windows and periodically different bars "twitch" and "reset for a second"
Edit
I just saw this first person SVG Demo So it can be done.
We are considering using SVG filters as part of our toolchain, serving the SVG to browsers capable of supporting it, while serving pre-rendered PNGs to other.
One problem we noticed is that the rendering of the filter chains seems to be very inconsistent across renderers. When looking at the "filters01" example from the SVG specification, the rendering looks very different across the tools we tried. Chrome (5.0.307.11) failed to render the image, while other tools (Firefox 3.6, Opera 10.10, Inkscape 0.47, GIMP 2.6.7) render something vaguely similar in style to the picture in the specification, but no two are truly the same.
Is that an issue of under-specification or are the tools just not there? If we would use SVG with filter effects: is there a reference tool that can give us a rendering the way it is intended by the spec?
Please report bugs on at least anything that doesn't look the same from a meter away to help improve the situation.