bug rendering equations in web interface

[sn6uv]

see screenshot:

first reported https://groups.google.com/forum/#!topic/mathics-users/3MO658UGaCo

[sn6uv]

This is another $OutputSizeLimit bug:

[teaalltr]

Maybe worths introducing some kind of output percentual check or measurement to cut off not atomic or unsignificant parts? The problem is: how to tell a perceptually atomic expression from a generic one? LHS of rules should be cut only if very very big (the user expects to see them). <<1>>s could be all relaxed if doing so does not exceed an (adjustable) percent of the ouputlimit. The same holds for <<2>> and <<3>>. The adjustable percent may be set by looking at the expression form: if we have a list of compound expressions, we can get the relative weight of each and doing some sort of weighted mean. If they're all big numbers, then we can cut them all, showing the first few and last digits, at most. If it's a mixed list, I'd personally give priority to the expressions - if not relatively too long. Presumably, Mathematica does likewise (they say that expression formatting code is hundreds pages long). Of course, being Python 100x slower or so, we'd better find a compromise

[sn6uv]

Complaints with the current system:

• should only omit middle elements (i.e. no omissions when <=2 leaves). e.g. in -4 a c in the above.
• should only omit when more than 1000 characters are to be printed (e.g. the above example had $OutputSizeLimit = 1000).
• doesn't count heads or spacing between items towards the limit. I tried to address this in OutputSizeLimit terminal enhancements  #597 but it's a bit more complicated.
• expressions with a large XML representation (e.g. Images) are almost always omitted, see OutputSizeLimit terminal enhancements  #597, problems described in more image docs and examples #571
• length of <<1>> isn't taken into account.

Perhaps we should revert #385 and #581 until this is sorted out.

[sn6uv]

workaround #611

[GarkGarcia]

This has now been fixed.