Consider a symbol that looks like this one: $a_b$

This question is about the behavior MakeBoxes on strings that contain boxes.

Try this: Iconize $a_b$ and then Un-Iconize it---no problem.

Now try this: Iconize the string "$a_b$" and then Un-Iconize it. You will see a bunch of escaped characters: "\(\*SubscriptBox[\(a\),b\)]\)". Iconizing is not reversible.

I think MakeBoxes is what is creating this behavior. Compare (replacing char with a_b):




Why is that happening and is there a good work-around to get Iconize to be reversible?

StringReplace[ "\!\(\*SubscriptBox[\(a\), \(b\)]\)", {"\\!" -> "", "\\(" -> ""}] is a possible work around, but is there something less kludgy?

  • 4
    $\begingroup$ Strings don't have subscripts in them, so if you have something that looks like a string with a subscript that is just the front end displaying the string nicely but not showing the actual contents of the string. Try ToString[<<your string here>>, InputForm] to see what it really looks like. $\endgroup$
    – Jason B.
    Commented Apr 2 at 20:33
  • 1
    $\begingroup$ @JasonB. It seems the "Uniconize" button in the iconized string is mis-parsing the string. The uniconized string has a syntax error. $\endgroup$
    – Michael E2
    Commented Apr 2 at 20:39
  • 1
    $\begingroup$ I guess I should point out that the outputs of uniconizing and MakeBoxes are different. So I don't think it's a MakeBoxes problem. Maybe. $\endgroup$
    – Michael E2
    Commented Apr 2 at 20:49
  • 1
    $\begingroup$ @JasonB. It's Mathematica that tells me there is a syntax error. No thought required: i.sstatic.net/QtfgZ.png -- A look at the box structure (Show Expression) shows it has a different structure than the input string: i.sstatic.net/2rkIx.png $\endgroup$
    – Michael E2
    Commented Apr 3 at 1:49
  • 2
    $\begingroup$ The problem is that the un-iconized output is a string, not an expression. "\"\\!\\(\\*SubscriptBox[\\(a\\), \\(b\\)]\\)\"" // ToExpression will evaluate the expression. $\endgroup$ Commented Apr 3 at 8:05

1 Answer 1


Uniconizing "\!\(\*SubscriptBox[\(a\), \(b\)]\)" // Iconize creates an ungrammatical box structure.

I see something different than what is being discussed in the comments ("14.0.0 for Mac OS X ARM (64-bit) (December 13, 2023)", in case it matters). And it seems to be a bug. The OP's remarks sometimes seem centered on a different issue. A clear use-case (example) is not given, beyond the one that led me to the issue below. The non-issue, which others focus on in the comments, is the string representation "\!\(\*SubscriptBox[\(a\), \(b\)]\)" of subscripts. The buggy issue is what happens to this when you iconize it and then uniconize it. The longer the discussion in the comments goes on, the more it seems likely that the OP is interested in the ameliorating the inconvenience of the non-issue in plot labels and has not noticed the issue below which addresses the code that was explicitly asked about. An XY Problem, perhaps.

The bug

One of the outputs in Out[301] below is the output of uniconizing and one is the output of FullForm — can you guess which?

enter image description here

But wait! The inputs in In[301] look the same! However their internal box structure is different. Here are the output cells generated by uniconizing Iconize and by FullForm:

enter image description here

$I.$ The syntax errors come from the individual "\"" and "\\!". When these are replaced by "Q" and "ESC", which strings represent symbols, the expression is parsed without errors. $\;{I}{I}.$ For some reason the strings "\\(", "\\) and "\\*" are ignored. RowBox[{"\\(", "a", "\\)"}] is interpreted as the String expression "a" (same for "b"). $\;{I}{I}{I}.$ The nested RowBox-es are interpreted as nested Times[] or function expressions. For instance, RowBox[{"f", "[", RowBox[{"x", ",", "y"}], "]"}] is f[x, y]. This construction appears once above with SubscriptBox for f. Note it is (i) RowBox[{"SubscriptBox", "[", ..., "]"}], not (ii) SubscriptBox["a", "b"], which is the box form for (iii) Subscript[a, b]. Box expression (i) is in effect the box form of the box form of (iii), but with nonstandard expressions for argument strings "a", and "b".

Here is what MakeExpression makes of the boxes from the uniconized string with the ungrammatical tokens "\"" and "\\!" replaced by "Q" and "ESC".

            , "["
            , RowBox[{
              RowBox[{"\\(", "a", "\\)"}], ",", " ",
              RowBox[{"\\(", "b", "\\)"}]}]
            , "]"}]}],
        "\\)"}]}], "Q"}]
  , StandardForm] // FullForm

(*  HoldComplete[Times[Q, Times[ESC, SubscriptBox["a", "b"]], Q]]  *)
  • $\begingroup$ You are right, the question would have been better had I articulated a use case. I had/have several problems in mind I thought they all stemmed from what I was seeing from MakeBox. However, the best use case example is this: When I iconify a something with a string that has boxes (often done with FrameLabel), the uniconified result is something that still works but is hard to edit (and is ugly). $\endgroup$ Commented Apr 4 at 13:23
  • $\begingroup$ And, thank you for that deep spelunking that you did above. $\endgroup$ Commented Apr 4 at 13:26

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.