bug with subscripts and superscripts in 3D

[alexcjohnson]

As reported by @ellecj - the problem has a couple of layers...

If I try to make this plot:

Plotly.newPlot(gd, [
    {
      "type": "mesh3d",
      "y": [0, 1, 2],
      "x": [1, 2, 0],
      "z": [2, 0, 1],
      "i": [0],
      "j": [1],
      "k": [2]
    }
  ],
  {
    "title": "Triangle mesh",
    "scene": {
      "zaxis": {
        "title": "Z<sup>SUPER</sup><sub>SUB</sub>"
      }
    }
  })

I don't see any super or subscripts:

And then if I do a relayout:

Plotly.relayout(gd, {'scene.zaxis.title':'ZZZ<sup>2</sup><sub>a</sub>'})

I see a superscript but not a subscript:

[etpinard]

Some info on the topic:

HTML entities are converted to unicode in src/lib/html2unicode.js. In particular <sup></sup> are converted using superscript-text which appears to work only for lower case strings inside the <sup></sup> tags. Indeed, lower case strings are working fine. This is tested in the gl3d_log-axis-big mock.

Note that html2unicode makes no attempt at converting <sub></sub>.

[etpinard]

Related: https://community.plot.ly/t/scatter3d-text-formatting/4039/2

[etpinard]

cc @dfcreative

[archmoj]

The example below is related to using lower case letters and <sup> which works with the PR #3207
Please note that here plus signs are used to avoid displaying the elements within <sup> tags to be parsed by GitHub viewer. Obviously one could omit them in the call.

Plotly.newPlot(gd, [
    {
      "type": "mesh3d",
      "y": [0, 1, 2],
      "x": [1, 2, 0],
      "z": [2, 0, 1],
      "i": [0],
      "j": [1],
      "k": [2]
    }
  ],
  {
    "title": "Triangle mesh",
    "scene": {
      "zaxis": {
        "title": "Z" + "" + "super script using numbers and only lower cases without" + "" + "'q'!"
      }
    }
  });

[archmoj]

Now in the PR #3207 the superscripts and subscripts could be used in webgl; and they are not limited to lower cases.

[vvch]

Now in the PR #3207 the superscripts and subscripts could be used in webgl

Thank you very much, it was very annoying bug. Maybe, it is also possible to use similar approach to fix related #608 bug?