Should I generate report graphics as PDF or SVG for 70% web, 30% print users? Or PNG?

Question

As a database guy, I hope my design-n00B question isn't noise!

I have some moderately complex data for which I want to generate (2-D) graphic representations on demand and also at intervals. I expect to use color but not subtle gradations.

I have generated GraphViz(.DOT) and I think I could generate SVG as well. I don't know what sort of libraries are available for generating graphs - I will be using Mac OS X or Linux. So I'm interested in suggestions for libraries or utilities as well.

I expect the primary consumption to be via Web. However, part of my audience is going to be printout-printout. Also, some of that audience will need PDF soft copy with these graphs embedded that can be printed remotely.

I'm prejudiced towards scalable formats, so I resist the ubiquitous PNG and JPEG. I'm also skeptical of using PDF which feels too cluttered and clunky. It seems that PDF also imposes a page size that I don't want constraining my graphics - but I could be wrong, of course!

So I'm strongly leaning towards generating SVG. Designers, I'm really ignorant of all the issues here, which is why I'm dropping in. Can you help me decide the format?

Answer 1

Without a doubt SVG is the way to go for Graph/Reporting online. It'll render on the web at any size and at any pixel density (retina displays). Usually has a smaller file size than PNG, as its in XML format it'll gzip nicely. SVGs will always stay sharp, PNG will loose it's sharpness if its scaled up or down.

D3.js is amazing for rendering visualisations. It is a low level graphics api. Which makes it really flexible but also more complicated. As it doesn't render charts out of the box, but there are loads of examples. It can render to PDF from the browser example

There are alternatives for out the box bar charts if your requirements are minimal. One being chart.js

The imposed size restriction from PDF are required for the standard paper size A4. Your graphics will be scaled to fit when printed.

D3 has some good colour palettes for charting too. Colour selection can be tricky, to make sure colours don't appear brighter or stronger than surrounding colours.

If your pipeline can generate .csv or .json files, there are frontend tools to render these to charts. Else if graphviz can generate the svgs and you're happy with the results, that'll work perfectly fine too.

Answer 2

I'm not sure that I have fully understood you final format for these graphs. Are they stand alone files that will be sent and viewed by users as a graphic file, or will they have additional narrative added in something like an MS Word document.

As a vector format .SVG is good for scaling without loss of quality, but in your situation how big are people going to want to enlarge these graphs. Is that an essential requirement? The problem with .SVGs, especially if you distribute them as a stand alone files is that they can only be used/seen in a limited number of applications - such as a browser. Should anybody ever want to embed your graph in an MS Word report then .SVG will be a problem.

If you want a format that is web and print ready and very widely accepted have you considered a high quality .JPG. Small file sizes, almost any application will recognise them and they should print OK for our users.

Tim

Answer 3

When it comes to SVG I typically do inline and style accordingly but for any animations I use jQuery. Here is a good example: "Animated SVG – Event Map" as your question would lead me to you are referencing geographical data.

Since you stated you would be using a narrative the inline approach will allow you to build circular objects or use markers with a tooltip that would display the text associated with that marker. If you wanted to get technical code an id or any form of identifier as a data attribute to target.

For the download aspect, just create form button for the file:

<form method="get" action="foobar.pdf">
  <button type="submit">Download PDF</button>
</form>

However, all of this will depends on if you want your PDFs to be searchable text. If you do want your PDFs to help your SEO then look at:

• Recommended way to embed PDF in HTML?

and you can code the suggested button for downloading. In regards to PNG, unless you plan to support IE8 fallback I wouldn't worry about it but do note you could code inline SVG and PDF as a fallback if you're trying to reference several large PDFs and are worried about page loads taking a long time.