33
$\begingroup$

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.

$\endgroup$
7
  • $\begingroup$ 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. $\endgroup$
    – Szabolcs
    Dec 12, 2013 at 22:18
  • $\begingroup$ 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. $\endgroup$
    – Mr.Wizard
    Dec 12, 2013 at 22:48
  • $\begingroup$ Funny, on windows copy and pasting into illustrator the point is to the left of the line. $\endgroup$
    – s0rce
    Dec 12, 2013 at 23:57
  • 2
    $\begingroup$ 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. $\endgroup$
    – Szabolcs
    Dec 13, 2013 at 17:11
  • 1
    $\begingroup$ The bug is still here in v.10.0.0. $\endgroup$ Jul 25, 2014 at 13:08

2 Answers 2

27
$\begingroup$

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).

$\endgroup$
6
  • 5
    $\begingroup$ 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. $\endgroup$
    – Szabolcs
    Dec 12, 2013 at 22:14
  • $\begingroup$ (+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. $\endgroup$ Dec 13, 2013 at 7:39
  • $\begingroup$ 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. $\endgroup$
    – Frank
    Oct 4, 2021 at 19:39
  • $\begingroup$ 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. $\endgroup$
    – Bill N
    Jun 17, 2022 at 11:40
  • $\begingroup$ @BillN Must be Windows specific. On macOS I did not see this. Yes, this is a very problematic bug. $\endgroup$
    – Szabolcs
    Jun 17, 2022 at 12:16
25
$\begingroup$

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.

$\endgroup$
3
  • $\begingroup$ 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. :( $\endgroup$ Jul 25, 2014 at 13:00
  • $\begingroup$ 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. $\endgroup$ Jul 8, 2015 at 8:42
  • 1
    $\begingroup$ Additional information from Sander Huisman: community.wolfram.com/groups/-/m/t/866997 $\endgroup$ Jun 3, 2016 at 11:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.