Plotting for publications.

[ma-laforge]

This "issue" is meant to help people who wish to generate plots destined for publications.

NOTE:

• The API of Plots.jl is mostly designed to make interactive plotting quick & simple.
• However, when targeting publications, one often needs to set more options to better control plot appearances.

Setting Defaults

I personally find it is easier to control the appearance of publication-plots by first setting the Plots.jl defaults:

using Plots

upscale = 8 #8x upscaling in resolution
fntsm = Plots.font("sans-serif", pointsize=round(10.0*upscale))
fntlg = Plots.font("sans-serif", pointsize=round(14.0*upscale))
default(titlefont=fntlg, guidefont=fntlg, tickfont=fntsm, legendfont=fntsm)
default(size=(800*upscale,600*upscale)) #Plot canvas size
default(dpi=300) #Only for PyPlot - presently broken

Please make sure to select the appropriate font size relative to the size of the plot canvas.

I also suggest to pick the same aspect ratio for the plot canvas size as will be used for the final image dimensions in the publication.

IMPORTANT:

• For most GUI-enabled backends, the figure size does not affect what is displayed on screen. The on-screen figure size typically under user control (i.e. when the window is resized).
• If implemented correctly, the dpi value should only affect the number of pixels used to generate pixel-based plot images (ex: .png files). It should not affect line thicknesses relative to total image size.
• If (most likely) the dpi feature is not implemented for your backend, then you will need to manually control the resultant "DPI" by up-scaling all the dimensions, widths, etc. See upscale variable.

Controlling Line Appearances:

When generating publication-plots, one should also exhert more explicit contol over how datasets are added to a plot:

plot!(x, y, linestyle=:solid, linealpha=0.5, linewidth=4*upscale, linecolor=:red)

One might also want to control the line thicknesses used to frame the plot/axes, or used by the grids.

• Unfortunately, I do not know how to do this. Someone please comment.

Embedding images in your publication

Most publishing suites will allow users to specify the physical size (ex: in cm x cm) of the image being added. So, as long as the plot was generated using the appropriate aspect ratio, there should be no issues.

The same is true for LaTeX:

\includegraphics[width=4cm,height=3cm]{./images/myimage}

More on Fonts

Warning: Some vector-based file formats (ex: .svg, .eps) might not properly embed font definitions within the image. This might cause issues where the publisher will have to substitute the desired font with a different one (or drop text all-together).

To avoid this issue, one can export to a pixel-based format (ex: .png, or .tiff) at the cost of image quality/file size. In this case, please ensure your resolution (i.e. total pixel count) is sufficiently large to maintain image quality.

[ma-laforge]

Please note that this "issue" should probably not exist as an "issue". I am mostly writing it in response to @spaceLem - but I have noticed similar questions from others.

At the moment: I am still unsure in which forum to add this information.

Maybe it would be best if this was part of PlotDocs?

[spaceLem]

@ma-laforge ideally, you're able to specify an image size (whether it be pixels, points, centimetres, or inches), and then all the font sizes and line weights that you specify during plotting will come out the right scale when you create your SVG file. If you instead want to create a PNG, then you specify the DPI, and it comes out correct.

Right now the issue is that I think you can only specify the size in pixels (and the resulting image is not that size), and the text doesn't seem to be editable in Inkscape, so I've got to resize the image and redo all the text manually. On the plus side, at least the contour plots I've been working on actually come out correctly, unlike in Octave where they are totally unusable when saved.

[mkborregaard]

It's nice to have some documentation of this. Let's keep it here for now. No doubt we need to come up with a good way of specifying the relationship between plot size and plot elements. At the moment, all steam in the JuliaPlots group is used to ensure the transition to Julia 0.6, but all these considerations are useful to have for later.

[ma-laforge]

@spaceLem: [...] If you instead want to create a PNG, then you specify the DPI, and it comes out correct.

This statement is probably not as accurate as you think: At the moment, only the PyPlot package implements the :dpi feature, and it does not handle it correctly.

The confusion with the :dpi feature is why I created issue #742 & pull request #740 .

@spaceLem: Right now the issue is that I think you can only specify the size in pixels (and the resulting image is not that size).

This might be true: As far as I know, the root of the problem is that Plots.jl never explicitly defined what these dimensions meant - nor are we verifying that all backends interpret the values the same way. I was partially trying to raise this issue in #733.

My suggestion: If you don't get the result you expected from your particular backend, try another.

If you want further help: Please reply with the generated plot image with undesired dimensions and the associated code used to generate it. It would be easier to find a solution (even if temporary) if we know exactly where the inconsistency occurs.

@spaceLem: [...] and the text doesn't seem to be editable in Inkscape

I noticed that the SVG files created with the InspectDR backend (using Cairo) were indeed "vectorized" as you described in another issue. This is good for publications because you do not have to rely on fonts being installed on the publisher's computer system.

But you are correct: "vectorizing" text means you cannot easily edit it using an external editor like Inkscape. However, you should still be able to scale up said text by stretching the group of letters.

Nonetheless: I would still suggest choosing a plotting backend that allows you to specify larger font sizes before plotting - rather than manually stretching text in an external editor after the fact.

[spaceLem]

@ma-laforge my comment about creating a PNG was how I thought it should work, not how I thought it did!

When it comes to journals, some are very strict requirements for figures (i.e. they must be exactly 8.5 or 18cm across, text must be Arial or Times New Roman and between 8 and 12pt, all lines must be between 0.5 and 2pt, etc.). I'm almost certainly going to have to use Inkscape to adjust things a bit, but it really helps if I can get as much right beforehand as possible (I have in the past opened up a Figure and replaced every single ticklabel, manually aligned them all, and reweighted every single line, to ensure it looks good and complies with journal requirements!). I'd really prefer to have the option of not vectorising the text, as I can always do it myself later on.

[nathancunn]

@ma-laforge I know this is an old issue now, but the defaults specified above don't do what you think they do.

upscale = 8 #8x upscaling in resolution
fntsm = Plots.font("sans-serif", 10.0*upscale)
fntlg = Plots.font("sans-serif", 14.0*upscale)

This actually sets the rotation of the text and not the size; size seems to expect an integer value. Probably best to specify by the keywords.

[ma-laforge]

Thank you. I had missed this. I'm a bit uneasy about the fact that a floating point value here is interpreted as a different quantity - especially since I would rarely think about rotation angle if I were saying something like a font of "sans-serif of 14.5".

Not to mention that I don't think there is a need to restrain font sizes to integer values. It is probably not necessary to use floating points by the time we use font sizes of 14+, but might come in handy with smaller font sizes (ex: 4.5).

Also, if I look at the Cairo manual, for example, font size is specified as a double:
https://cairographics.org/manual/cairo-text.html#cairo-set-font-size

[hurricane007]

Good to find this thread.
I would suggest having " grid=:off, box=:on " as the default plotting so it looks more like publication-ready: