Feature request: option to show raw text instead of Markdown

[netheril96]

Most of the time I need to view the raw text rather than markdown rendered. Currently I wrap the generated text with <pre> and </pre> to avoid symbols being interpreted as style markers, but because the text is generated by a RNN, it sometimes contains </pre> itself to break the whole thing.

I believe a checkbox on Tensorboard that turns off Markdown would be really helpful to many people, and it shouldn't be much work, since displaying text without formatting seems a much easier job than markdown rendering.

[chihuahua]

@netheril96, do you have input on #832? Thank you for the idea.

[netheril96]

The PR, judging from its description, is exactly what I need. I don't know how to try it though.

[chihuahua]

To try it out in its current state, you have to install bazel, then follow the instructions in https://github.com/tensorflow/tensorboard/blob/master/DEVELOPMENT.md that relate to building and running via bazel.

[silky]

what's the update on this?

it'd be super handy to be able to render html in the text fields, instead of markdown (for say visualising the output of attention models).

it seems that it isn't supported presently.

[nfelt]

@silky There's no update on this issue, which is actually about allowing you to disable markdown interpretation entirely, somewhat different from your requested feature of direct HTML rendering. Rendering arbitrary HTML would make running TensorBoard on any untrusted event data dangerous because of the possibility of injecting malicious HTML into the page, so I'm afraid I don't think we would want to add that feature unless we had a good way to address the risks.

[silky]

@nfelt

an easy option is just make it a param to running the tensorboard server itself

tensorboard --logdir whatever --render-arbitrary-html

then it can be disabled by default, but an option for those who are working in a suitable environment.

[nfelt]

It's something we could consider, but IMO still pretty risky since likely at least a few people would forget to stop passing that flag when handling untrusted data. For now at least, Markdown was our compromise option to allow some formatting while keeping things much safer than arbitrary HTML.

What kind of HTML rendering would you need to do? We're hoping to make the plugin system a bit easier to use and potentially the more "custom HTML" use cases could be addressed by a plugin in a way that's both safer and overall better supported than borrowing the text dashboard for this.

[silky]

i just want a simple visualisation for an attention model; i.e. i want to write text, and then colour in specific words:

it can be hacked ( facebookresearch/pytext#171 ) by doing it via images, but that's pretty crazy. it'd be nice if it could be done just via the text summaries.

i'm not necessarily against a new plugin, but it seems overkill. i'd probably just do the image hacking style.

[nfelt]

@silky Ok, can you open a new feature request for some way to support this? Maybe it doesn't need a new plugin but IMO there are still safer ways to do this than opening up arbitrary HTML. E.g. we might be able to add a markdown extension that lets you do varying levels of highlighting for this purpose.

[silky]

@nfelt done - #1740

[vengodelsur]

(If you came here when searching for a workaround just like me, you should know that seamingly you can add four spaces at the beginning of each line so that text is treated as a code block and inside it formatting isn't used.)

[lostmsu]

I consider the current implementation half-baked because it treats all whitespace characters as space.

For instance, I wanted to log code version to tensorboard for reproducibility. My instinctive move was to have two fields: one for commit hash (that one is not the problem), and the other one for git diff output. It is the latter that gets garbled new lines when I disable the Markdown option. E.g.

[nfelt]

@lostmsu If that's what you need, can't you just keep markdown enabled and wrap the diff in a code block?

[lostmsu]

@nfelt as mentioned elsewhere the problem is that the diff might have markdown elements in it.