Strange behavior in graphs exported as pdfs

I observed the following odd behavior when plotting my own data, but I have made a minimal (non)working example to illustrate the issue.

First, I made a 900-point wave ("square") scaled from 0 to about 28 (doesn't matter), then filled it in using

square = (sin(x) > 0) - 0.05*x

I then plotted it (in red) with:

  • Lines between points
  • Size: 2
  • Join: Bevel
  • Miter limit: 10
  • Cap: Flat

I also plotted it on the same graph (blue) with Mode: Lines between points and Size 0.1, and offset it vertically for clarity.

If you zoom *way* in to the pdf (say, 1200), you can see some of the anomalous plotting. First, there are occasional breaks in the red trace. A clear one appears at about x = 20. Second, the sloped part is rather jaggedly, even though in principle the data in this part has a uniform negative slope. Zooming even further in (2400x), it looks like the thin blue trace consists of alternating horizontal and sloped segments, rather than all segments having the same appropriate negative slope.

It might look like I'm nitpicking here, but these issues are actually rather obvious to me in the actual data I am trying to plot.

Any ideas as to what's going on? 

A pdf of the issue. Zoom in to 1200 or 2400 to see it. An experiment of the issue

I tried saving the graph as a svg so that I could inspect the resulting code. The "line to" codes for the traces start with "L443,100 L446,100 L448,101 L451,102 L453,102..." You can see that (a) the resolution of the vertices is only 1 unit (not clear what these units are, but the whole graph extends from about 0 to 3000 units), and (b) the y values are often repeated in pairs, presumably leading to the horizontal segments I observed in the pdf. So maybe the issue is that Igor is not creating pdf/svg code with a high enough resolution (?)

Igor draws with integer values (scaled to a high resolution).

Nearly identical floating point values may truncate/round to the same scaled integer depending upon how high the resolution is.

Is there a way to use a larger scaling factor? Would it help to make my entire graph 4x larger, including things like 8 pt traces and 48 pt fonts?

Also, any ideas on the small gaps or breaks in the traces?

By default the resolution is 8 times the screen resolution, so making the graph bigger will improve the situation.

On Windows this normally 768 dpi.

You can use SavePICT/RES=1200 to get better results, too. 1200 is the max allowed right now for PDFs even though /RES accepts up to 4800.

The 1200 dpi limit is to prevent integer overflow in some graphic coordinate calculations.

We look forward to the day when we have the time to convert all of our drawing code to floating point, though it might draw a bit more slowly...

 

We might also ask why you need a PDF that will do this. You can zoom inside of Igor directly on the graph and get better behavior.

I am creating a pdf (not of the test file I attached) for a publication-quality graph to be sent to the journal. Obviously I would like this to look as good as possible, as well as being as faithful to the real data as possible. Because of the integer truncation this is not quite the case.

I did find that by changing the join style to "round" the graph is now acceptable. Also, the /RES=1200 had no discernible effect. I thought that /RES was only for bitmaps?

 

Even when I am only creating the graph in Igor the zoom does not always look very good. The file attached is a screenshot of what my real data graph looks like zoomed in 8X. There are all sorts of artifacts. Fortunately the pdf looks better.

You might try setting the graph expansion back to 1 (it is set to 3 in the experiment file), or potentially even lower. I seem to be getting better results at expansion <= 1. 

Also, since saving graphics from a graph window is dependent on the size of the graph window for how it looks, you might consider adding the graph to a layout first, positioning and sizing it as you want, and then saving the layout as a pdf. You can build an entire figure this way, and size it according to the journal's column specification. Here's an example single and double column version at expansion=1, it looks pretty good artifact-wise for both.

Layout0.pdf