33

Bug introduced in version 9.0 and persisting through 10.4

Graphics elements do not always line up perfectly in exported PDFs using "Save As..." method.

Take, for example:

 Graphics[{Point[{0, 1}], Line[{{0, 0}, {0, 1}}]}, AspectRatio -> Automatic]

It looks like this on screen:

Notice that the dot isn't centred on the end of the line.

Now let's export to PDF (hoping that what we saw displayed in the Mathematica GUI is just a rendering problem). Right click the graphic, and choose Save As... -> PDF. The PDF looks like this when magnified in a viewer:

There is clearly a very serious misalignment. Is there a workaround?

Note: this seems to be a new problem in version 9. Version 7 and 8 are not affected.

Szabolcs
  • 234,956
  • 30
  • 623
  • 1,263
  • This gave me a really hard time so I thought it was worth mentioning here. Note that it also affects copying to the clipboard. Copying is very convenient on OS X when pasting into Illustrator or PowerPoint, so I used it a lot. – Szabolcs Dec 12 '13 at 22:18
  • I don't have this problem in version 7 under Windows 7. The graphic looks misaligned in the Notebook, but context menu Save Graphic As... produces a correct PDF. +1 for debugging nevertheless. – Mr.Wizard Dec 12 '13 at 22:48
  • Funny, on windows copy and pasting into illustrator the point is to the left of the line. – s0rce Dec 12 '13 at 23:57
  • @Mr.Wizard Version 8 seems to be fine too. – Szabolcs Dec 13 '13 at 01:42
  • 2
    I tagged this as a bug after finding out that the problem is new in version 9 and didn't exist in 7 or 8. – Szabolcs Dec 13 '13 at 17:11
  • Save As... looks fine but Save Selection As... has the problem you described here. My system is 9.0.1 on win8.1. – Silvia Dec 15 '13 at 05:36
  • 1
    The bug is still here in v.10.0.0. – Alexey Popkov Jul 25 '14 at 13:08

2 Answers2

27

A simple workaround is to use Export instead of right clicking and choosing Save As ... The result will look like this:

Much better.

It's not clear to me why this difference exists between saving from the front end or using Export, but there is a significant difference in the quality of the output. Notice that the line widths are different too (the Export version is correct).

Conclusion: better not use the interactive Save As feature for graphics, or copy the graphic to the clipboard on OS X (which will have the same rendering imperfections).

Szabolcs
  • 234,956
  • 30
  • 623
  • 1,263
  • 5
    My guess is that the front end is snapping coordinates to align with the screen's pixel grid before rendering anything, and that this coordinate modification persists even after saving the graphics to a vector format. I think it's also the reason why I sometimes got zig-zaggy tick marks. – Szabolcs Dec 12 '13 at 22:14
  • (+1) Very interesting observation! The difference between PDF exported via FrontEnd and Export always puzzled me. I knew that FrontEnd samples metafiles with screen-resolution fidelity but never thought that the same is applicable to PDF export via FrontEnd. – Alexey Popkov Dec 13 '13 at 07:39
  • A similar problem exist of misalign graphics label on version 12.2 and 11.3, but which worked two years ago, maybe the windows system version change is the reason? Export works well though. – Frank Oct 04 '21 at 19:39
  • Export is causing the same problem for me using 12.2 with Windows 10, so perhaps this functionality is broken now. The misalignment occurs regardless of what file format is exported. What works now is to Rasterize the graphic first, which preserves the alignment whether cutting and pasting, exporting, or saving the working notebook as a pdf. – Bill N Jun 17 '22 at 11:40
  • @BillN Must be Windows specific. On macOS I did not see this. Yes, this is a very problematic bug. – Szabolcs Jun 17 '22 at 12:16
  • @Szabolcs Ah! Thanks for the info.. I'm getting into the habit of using Rasterize while building complex graphics (such as adding annotations and Callouts to plots), just to avoid this pesky alignment problem when later PDF'ing or cutting/pasting to another document. A lot of overhead since the graphics are now images, but it gets the job done. – Bill N Jun 18 '22 at 11:46
25

Proof of the Szabolcs's idea:

Graphics[{PointSize[0.001], Point@RandomReal[1, {1000, 2}]}, ImageSize -> 30]

enter image description here

After Save As (28x28 grid):

enter image description here

After Export

enter image description here

Another workaround is printing the graphic to a file.

Szabolcs
  • 234,956
  • 30
  • 623
  • 1,263
ybeltukov
  • 43,673
  • 5
  • 108
  • 212
  • Very cool! My respects. I did suspect this for a long time but was not able to find any proof of concern. P.S. Still the same behavior in v.10.0.0. :( – Alexey Popkov Jul 25 '14 at 13:00
  • The same behavior in v.10.1.0: Save Graphic As... and Copy As produce the on-screen version of graphics (size and resolution are proportional to the Magnification setting), while Print Graphic... prints with much better precision but still is 100 times less precise than Export. – Alexey Popkov Jul 08 '15 at 08:42
  • 1
    Additional information from Sander Huisman: http://community.wolfram.com/groups/-/m/t/866997 – Alexey Popkov Jun 03 '16 at 11:13