Bug introduced in 11.1 and persisting through 11.3

When the first argument of Text is a Graphics, and the third argument (offset) is used, positioning is incorrect in M11.1 and M11.2. Mathematica 11.0 behaves correctly.


inset = Graphics[{Circle[{0, 0}, 2]}, Frame -> True, 
  FrameTicks -> None, ImagePadding -> 1, PlotRangePadding -> None, 
  ImageSize -> 90]


figure = Graphics[
  {Text[inset, Scaled[{0.5, 0.5}], {1, 1}]},
  PlotRange -> {{0, 1}, {0, 1}},
  Frame -> True,
  GridLines -> {Range[0, 1, .1], Range[0, 1, .1]},
  ImageSize -> 360

Incorrect positioning

(This is wrong)

With the {1,1} offset, the upper right corner of the inset should line up with the middle of the plot range in the enclosing figure.

In Mathematica 11.0 we get the expected output:

Correct positioning

In M11.1 and 11.2 we also get a correct positioning if the inset is a general notebook expression instead of a Graphics. We can, for example, wrap it in Framed to achieve this.

figure = Graphics[
  {Text[Framed[inset], Scaled[{0.5, 0.5}], {1, 1}]},
  PlotRange -> {{0, 1}, {0, 1}},
  Frame -> True,
  GridLines -> {Range[0, 1, .1], Range[0, 1, .1]},
  ImageSize -> 360

Correct positioning with Framed

Is there a workaround for this bug?

This bug is of concern to me because MaTeX-generated expressions are supposed to be a drop-in replacement for text. It is supposed to work when written directly within Text. But MaTeX outputs Graphics, so it is affected by this bug. In some situations, the user can't even control if some expression they input will be used inside of a Text or an Inset.

  • 2
    $\begingroup$ Exceptionally, I am tagging this as bugs from the beginning as it has been confirmed by support in CASE:3943734. $\endgroup$
    – Szabolcs
    Commented Sep 19, 2017 at 20:10

1 Answer 1


Skip to the end for a workaround.

Understanding the bug

To understand the underlying cause of the bug, let us cycle figure through a box representation and look at its input form. This can be done by converting the output cell to input form (Command-Shift-I) or programmatically using


Notice that instead of Text, in 11.1 and 11.2 now we have an Inset equivalent to

Inset[inset, Scaled[{0.5, 0.5}], {1,1}]

In 11.0, we have

Inset[inset, Scaled[{0.5, 0.5}], ImageScaled[{1,1}]]

Looking at the documentation of Inset, we see that the third argument is interpreted as a position within inset. If inset is a general notebook expression (like Framed or text), then the offset position goes from 0..1. If inset is Graphics it is interpreted as plot coordinates.

In Text, however, it is supposed to go from -1..1 regardless of what expression Text contains.

When converting a Text to an Inset, the offset position must be converted too. {1,1} should convert to ImageScaled[{1,1}] and {-1,-1} should convert to ImageScaled[{0,0}]. See ImageScaled.

This conversion does happen in M11.0 and earlier but not in M11.1 and M11.2.

The workaround

The workaround is to use ImageScaled directly within Text:

Text[inset, Scaled[{0.5, 0.5}], ImageScaled[{0, 0}]]

Of course, if we do so, we might as well use Inset instead of Text. However, both work when the offset coordinates are ImageScaled.

If you cannot control whether Inset or Text is going to be used in some context, use Framed[inset, FrameMargins -> None, FrameStyle -> None]. This does add a tiny margin, but in practice it is very usable.


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.