OK, no stats today, just fidgeting about with graphics devices and type faces. Caveat - the details of graphics formats and typefaces is not my area of real expertise, this blog post is me noting down things that I found useful and others might too. As always, corrections and comments are very welcome.
There are two main types of computer graphic formats:
- vector graphics, where the file is basically a set of instructions (start at x, draw a line at 30 degrees angle for y units, draw a circle of radius w centred at z, etc). Like something you generated with Inkscape or Adobe Illustrator.
- raster or bitmap graphics which are basically an array of numbers telling the computer which how to colour each pixel. Like a digital photograph.
Generally vector formats are far superior if you have the choice but large complex graphics (eg with millions of points, or maps with many fiddly bits) can be slow to render (and large to store). And until relatively recently many users’ web browsers could only show bitmap graphics. Internet Explorer 8 was the last high-use browser of this sort we had to worry about.
For my blog I work almost purely with Scalable Vector Graphic (SVG) format by choice, and PNG (a relatively efficient and high quality bitmap format) when I have to.
My graphics workflow for this blog is generally:
- Write the graphic to a Scalable Vector Graphic (SVG)
- Convert the SVGs to PNGs in batches using ImageMagick
I use the SVGs on the web pages that make up this blog; I need the PNG copies for posting on Twitter, Facebook and LinkedIn which don’t take SVGs, and also for some complex objects that would be too large as SVGs.
A quick aside on anti-aliasing
To get in the groove of thinking about graphics I’m going to start with the concept of anti-aliasing. Here are three closeups of a straight line in a computer graphic, generated in R by three different graphics devices. From left to right these were generated by
Aliasing (in graphics) refers to the jagged staircase-like bits of an image from approximating an ideal shape with crude collections of pixels. Anti-aliasing is basically the smoothing or blurring process to try to make the problem less obvious.
On a Windows machine (where I spend nearly all my working time), the
png() device, no matter high a resolution you specify, will not use anti-aliasing and close ups of the image will reveal jagged bits like that in the right of the three options above. At the opposite end, a graphic that has been saved as SVG won’t have any aliasing at all coming from the file format itself; any jaggedness comes from the final rendering of the information in the file onto the screen (in the end, everything has to become pixels to get on the screen), not from how you generated the file.
The Cairo option in the middle has anti-aliasing taking place when the PNG file itself was generated. Files generated with
CairoPNG() look much better than those from
png(), but still can’t compete with the vector format even when the PNG is high resolution (eg 720 or more dots per inch).
Here’s the code that generated these examples
Potentially useful whimsical tip: once your awareness is raised about the need for anti-aliasing, you might become painfully aware of those unprofessional looking jagged bits in graphics. When working interactively in RStudio on Windows, all the graphics in your plot pane will look this way. If this hurts you like it hurts me, you can bring up a anti-aliased window with
CairoWin()and plots will be rendered nicely on that window, and look much better than the crude default renditions. If you’re using two screens it’s also convenient for placing on your second screen.
Different flavours of SVG
Until recently I’ve been generating my SVG files with
CairoSVG(). However, I’ve gotten very disatisfied with how text is rendered by that format. It’s hard to put my finger on what is wrong, but it looks blurry, particularly when it’s about 10 point in size which of course is nearly all the time in statistical graphics. Sometimes the problem goes away when you zoom in, but that isn’t really the point.
I eventually solved this problem by moving to the excellent
svglite package by Hadley Wickham, Lionel Henry, T Jake Luciani, Matthieu Decorde and Vaudor Lis.
svglite creates smaller and faster SVGs and has a much better treatment of text in particular. But
svglite alone wasn’t enough for the way I needed typefaces treated - I’ll get to that later.
To go into this further, here are three different SVG files, rendered in this web page as images, created by
The first two approaches are very similar, but the
svglite philosophy is quite different.
svg take text and turn it into many tiny shapes to draw; whereas
svglite keeps the text as text in the SVG file and leaves it to the end user’s computer to render it. Zoom in close on any of those images above and the text will magnify nicely; but something about the relatively complicated approach of the first two makes them look a little blurred and complex when they’re looked at from a distance. This is the process of turning the text into individual shapes, interacting with the final rendering on the screen in some way that I don’t want to have to understand.
SVG files are just text files (in XML format) so we can look at the actual code (a huge advantage of SVG over other formats). Here’s the full text of the SVG generated by
… and here it is for the SVG generated by
svglite version is much shorter because instead of describing exactly how each character looks, it just says “write ‘Hello world’ in the middle of the graphic, at 60 points in size, using the Indie Flower font family”.
That last point - “using the Indie Flower font family” is important too. It means that this font family needs to be available at the point the SVG file is rendered on-screen ie the end user’s machine. Whereas in
svg, no font family is recorded in the SVG file itself, the font family is taken into account at the generation of the SVG and has to be available on the developer’s machine.
As it happens, the “Indie Flower” type face isn’t installed on my computer and probably isn’t on yours either. When R encountered an instruction to use a typeface it didn’t know, it fell back on Arial and that’s how the two images on the left were generated. When a web browser encounters such an instruction, it falls back (at least if it’s Chrome or Edge) on Times New Roman or equivalent. This is why the image on the right looks different to the other two - it’s a question of a web browsers fall-back type face, compared to R’s.
Here’s the code that produced those three images and got the code from the SVG files to put in this blog post:
Solving the web font problem for svglite
So, I much preferred the smaller size, faster creation and download, and better look for text from
svglite - but I had a new problem, of how to get custom fonts rendering reliably. I use web fonts from Google for my web page to get my HTML/CSS consistent with the graphic images, so in practice I need a way to render Google web fonts in SVGs, regardless of whether the user has them on their end computer or not.
svglite has a
user_fonts argument that is meant to embed fonts that are on the developer’s machine inside the SVG if desired, but as far as I can tell it doesn’t work. So I forced myself to look a bit into how the SVG format works, and after wading through a number of out of date bits of info on the web eventually realised that I just needed the line
@import url('https://fonts.googleapis.com/css?family=Indie Flower:400,400i,700,700i'); added (for the Indie Flower case). So the
svglite file above just needs to become as follows:
This renders nicely, with the correct typeface and all:
… albeit with one last change necessary to how I organise my blog. I used to include my SVG files in the blog using the
<img> tag, such as:
An SVG file that is called into a webpage by
<img> is not allowed to get information from external sites. It has to instead be included with an
<object> tag as follows:
This has the disadvantage that a user can no longer right-click on the image and save it. They can still view the “frame source”, copy it into a text editor and save it from there, but that’s going to put off a lot of users who aren’t used to thinking of an image as being fully represented by a bunch of code that can be pasted into Notepad! I imagine I’ll think of something to get around this.
Embedding my SVGs with
<object> is also necessary if I want to incorporate interactivity (eg tooltips or more), so it’s probably a good habit to get into.
I knocked up a quick and probably non-robust hack of a function
svg_googlefonts() to add the necessary font imports in
<style> tags to an SVG generated by
svglite. Usage is exceptionally simple. It takes a previously created SVG file (in this case, the “0150-svglite.svg” file created earlier in this post), the name of the Google fonts (one or more) to insert, and saves as a new version (or over the original, which is the convenient default for how I’ll be using it):
That’s now in my
frs R package of convenient utilities associated with this blog.
That’s all for now. In summary:
svglitemakes fast, small, well-rendered SVG images which treat text the way SVG is designed to
- but if you want to use typefaces that aren’t going to be on every user’s machine you need to embed them in the SVG or have the SVG import them. My
svg_googlefonts()function helps you with the latter, and the resulting SVG files need to be included in web pages with the