Implementing svglite

[dlcomeaux]

NB: This issue is a consolidation of components of several previous issues (primarily #91 and #127), which have been or will shortly be closed over time as the package has evolved. They are referenced throughout.

The cmapplot package currently relies on the svg device to export SVG graphics. As noted in #91 , the images exported using this device have two related problems:

• They are corrupted when opening in Illustrator, although they load properly in web browsers.
• The text is encoded as polygons, rather than text. For some circumstances, this may be desirable (for example, some web publication where variations in font rendering will negatively impact readability - for more detail, see Noel's comment here), but there are instances where text encoding would be preferred.

The svglite package would ideally solve both of these problems. In particular, svglite encodes text as text, rather than polygons.

In #127 , one of our goals was to implement the migration from svg to svglite. At its most basic, this can already be achieved by changing the device name for SVG exports from svg to svglite in the relevant line of finalize_plot.R (this was done, and then undone, in #130 ). However, SVGs exported using the svglite device using Whitney appear to have different font weights than those exported using svg, as well as any of the other graphic devices. In particular, the chart titles, which should be exported in Whitney Semibold, appear instead too similar to other exported text.

I explored this discrepancy here. It appears that svglite is converting our various fonts (Whitney Semibold, Whitney Book, etc.) into fonts of the Whitney family of different weights. However, those weights are not sufficiently distinct from one another to render at the appropriate boldness. If you open the SVG in a text editor, it shows that the "font-weight" is listed as 375 for semibold, 350 for medium, and 325 for book (vs. the higher values that appear to be standard of 600, 500, and 400, respectively). It may also be useful to know that svglite is not uniform in converting weights into numeric versions - I tested a bold version of Calibri and the "font-weight" was "bold" - which exported in bold as expected.

I am not sure why this is happening, and where the different weights are being derived from. When I explored the current fonts on my system using systemfonts::system_fonts(), I noticed that most of the Whitney fonts are actually missing their weight attribute, which could have something to do with it - but that might also be irrelevant. I also saw that the list of registered fonts (using systemfonts::registry_fonts()), all fonts do have weights, but they are only "normal" or "bold."

In general - I am confused about this! @matthewstern and I thought it would make sense to table this issue for now, implement the rest of #123 , and come back to this if/when we come up with any ideas on how to solve it. A few ideas for possible testing:

• Use the (eventually to be deprecated) user_fonts and system_fonts arguments to svglite, as they may allow us to more clearly specify which fonts we want the device to use. This is documented here.
• Explore the web_fonts argument of svglite. This is documented to some extent in the announcement of svglite 2.0.0,
• This older article predates the launch of svglite 2.0.0, but may still provide avenues for testing. It explains and explores the different SVG graphics devices.

---

For reference, the "vanilla" svglite export of our test fonts looks like this. When modified to use the weights above, it looks like this.