FullGraphics hasn't worked entirely for a long time and the situation appears to be getting worse instead of better. In Mathematica 10.0, 10.1, 11.3, 12.3 up to 13.1 a simple usage throws numerous errors and returns a graphic without ticks and with the wrong aspect ratio:

Plot[Sin[x], {x, 0, 10}] // FullGraphics

Axes::axes: {{False,False},{False,False}} is not a valid axis specification. >>

Ticks::ticks: {Automatic,Automatic} is not a valid tick specification. >>

(* etc. etc. *)

This may be caused by or related to More Ticks::ticks errors in AbsoluteOptions in v10.

It seems that I must go back to version 5 functionality if I want this function to work right:

<< Version5`Graphics`  (* load old graphics subsystem *)

Plot[Sin[x], {x, 0, 10}] // FullGraphics

enter image description here

I wonder at this point if there is any indication that FullGraphics and perhaps also AbsoluteOptions are still supported? Or has something to the contrary has been written (Wolfram blog, a developer's comment, etc.) that indicates these should be removed from the documentation now?

With FullGraphics broken is there a method that can take its place for producing proper Graphics directives that may be further manipulated and combined, not merely vectorized outlines?

  • 2
    $\begingroup$ Good question. (IOU one upvote.) When I made the jump from version 5 to 8, it was one of the differences that struck me, since it broke some of my tricks, and thus had to resort to alternatives. So it has become even less useful now, it seems. $\endgroup$ May 17, 2015 at 10:33
  • 1
    $\begingroup$ When you find an answer, you might want to add a post in the mathematica.stackexchange.com/questions/43631/… thread. $\endgroup$
    – Peltio
    May 17, 2015 at 13:45
  • $\begingroup$ @Peltio I never saw that question until now. I started and maintain one that is fairly similar: (56728). I hope the emphasis of these questions is different enough that mine is not a duplicate. (I seek to extend missing documentation as it were.) $\endgroup$
    – Mr.Wizard
    May 17, 2015 at 13:49
  • 8
    $\begingroup$ How related is this code: Plot[Sin[x], {x, 0, 10}] /. {HoldPattern[Frame -> _] -> Frame -> False} // FullGraphics $\endgroup$
    – Junho Lee
    May 17, 2015 at 14:32
  • 2
    $\begingroup$ The problem persist in 11.3 and the function hasn't been removed from the documentation. The developers are aware of the issue and there is an ongoing support case. CASE:3897155. $\endgroup$
    – rhermans
    May 29, 2018 at 16:35

3 Answers 3


It seems that the problem appeared in the version 5-> 6 transition.

<< Version6`Graphics`
InputForm@ListPlot[{{0, 0}}]
(* Graphics[{...
Frame -> {{False, False}, {False, False}},...] *)

which has the same form in later version. This subtle difference is causing the trouble. c.f.

 << Version5`Graphics`
InputForm@ListPlot[{{0, 0}}]
(* Graphics[{...
Frame -> False,...] *)

This bug can thus be circumvented by manually changing this value.

FullGraphics @@ (InputForm[Plot[Sin[x], {x, 0, 4}]] /. 
Rule[Frame, _ ] -> 
Rule[Frame, False])

Basic implementation

After working on this answer, I realized that the undocumented FrontEnd`ExportPacket with "InputForm" as second argument may be considered as an alternative to FullGraphics. First, a basic definition:

fullGraphicsBasic[expr_, dist_ : 1.2] := Block[{e = dist}, ToExpression[
     FrontEnd`ExportPacket[Cell[BoxData@ToBoxes[expr]], "InputForm"]]]]

Here is a demonstration of how fullGraphicsBasic works (Mathematica 13.1.0):

Plot[Sin[x], {x, 0, 6 Pi}]




The axes and ticks look lighter than they are on the original figure due to the default Antialiasing -> True applied to the graphics primitives (by default Axes and Frame are rendered with Antialiasing -> False). We can fix this, for example, as follows:

fullGraphicsBasic[Plot[Sin[x], {x, 0, 6 Pi}]] /. 
 AbsoluteThickness[0.2`] :> Sequence[AbsoluteThickness[0.2`], Antialiasing -> False]


Discussion and better implementation

I was forced to wrap the main code of fullGraphicsBasic with Block, because for some reason it returns an expression with undefined variable e, which determines the distance between the minus sign and the number. The minus signs are separately drawn as Style["-", FontFamily -> "MathematicaSans"], while the numbers are drawn with FontFamily -> "Arial". Surprisingly, the "Hyphen-Minus" characters "-" look the same (at least on Windows 10 x64) in these fonts, so this complication is completely redundant. But it makes a trouble, because the correct value for this variable seemingly depends on where the number is placed on the plot. The same problem applies to some other mathematical characters, for example: ~, ±, = etc. Applying PrivateFontOptions -> {"OperatorSubstitution" -> False} doesn't change this behavior.

This feature/bug is present in all versions I checked: 8.0.4, 12.3.1 and 13.1.0, excepting version 5.2 where the method itself doesn't quite work. It is interesting, that if I specify "Output" as a style for the Cell in the definition above, this undefined variable e disappears and the result looks as if it is replaced with 1.8 (as a consequence, the minus sign runs over the number). These observations indicate that this functionality of FrontEnd`ExportPacket is still incomplete.

As a workaround to this horrible feature, one can replace the "Hyphen-Minus" character with zero before applying FrontEnd`ExportPacket, and then replace it back after it. Since we are most interested in reproducing the Ticks and FrameTicks, we can proceed as follows:

fullGraphics[expr_] := Module[{e},
   e = expr /. 
     g_Graphics :> 
      Show[g, AbsoluteOptions[g, {Ticks, FrameTicks}] /. 
        s_String :> 
          s, {StartOfString ~~ "-." -> "00.", StartOfString ~~ "-" -> "0"}]];
       FrontEnd`ExportPacket[Cell[BoxData@ToBoxes[e]], "InputForm"]]] /. 
    Text[Style[s_String, opts__], c__] :> 
          s, {StartOfString ~~ "0" ~~ d : DigitCharacter :> "\[Minus]" <> d}]}], opts], 

News about FullGraphics and AbsoluteOptions

This CW answer is intended for collecting the ongoing information about changes in FullGraphics and AbsoluteOptions through the versions.

I wonder at this point if there is any indication that FullGraphics and perhaps also AbsoluteOptions are still supported?

In version 13.0 was "substantially updated implementation" of AbsoluteOptions, and later after update in version 13.1 it "can resolve more 2D and 3D graphics options". Detailed information is not provided in the documentation, but at least now the long-standing bug in determining PlotRange via AbsoluteOptions is fixed. Also, the "Incompatible Changes" page has a notice for version 13.0:

AbsoluteOptions has been reimplemented to be more accurate, and the form returned for a particular option may be different now.

It is also worth mentioning that there is ResourceFunction["GraphicsInformation"] which allows to obtain the true absolute values for some Graphics options even in the versions before version 13.0.

Concerning FullGraphics, rhermans reported here at May 29, 2018:

The developers are aware of the issue and there is an ongoing support case. CASE:3897155. – rhermans May 29, 2018 at 16:35

But I don't see any improvement in behavior of FullGraphics up to version 13.1. Probably this bug has low priority due to low number of bug reports.

To the above, it should be added that in version 12.3 AxisObject was added, which greatly facilitates the reconstruction of the plot axes based on the information that can be obtained through AbsoluteOptions.


Your Answer

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

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