Talk:Superellipse

Formulae now invisible on standard OS X browsers

May need tidying up to achieve formula visibility on the OS X platform. Problems may include flanking of LateX expressions with redundant white space inside <math> tags Hout (talk) 13:29, 16 September 2016 (UTC)

Not all OSX browsers, so far I have only seen the problem with Safari and Chrome. This is not limited to math markup, though - I have been seeing many many images fail to load under Safari. Perhaps we should be recommending that OSX users switch to Firefox? --Rdm (talk) 13:34, 16 September 2016 (UTC)

I don't think so - the problem is new and quickly fixed - pruning back the newly-introduced redundant spaces will restore visibility on the major browsers on that platform. If we do want to understand the etiology, then we probably need to look at the Latex -> HTML stage of the wiki software. But the experimental result is already clear. Adding that space adds nothing for the users, but does prevent significant numbers from seeing the formulae. Hout (talk) 13:42, 16 September 2016 (UTC)

Then perhaps we are seeing different problems, or different aspects of the problem, at least. Trimming those spaces does nothing for me, and I have been seeing blanks for math markup for months. --Rdm (talk) 14:31, 16 September 2016 (UTC)

Formula visibility can be consistently toggled here by introducing and removing a leading or terminating space, before or after the Latex expression, in a <math> tag:

<math>Latex</math> ⇄ <math> Latex </math>

(Chrome Version 52.0.2743.116 (64-bit), Safari Version 10.0 (12602.1.50.0.8)) Hout (talk) 14:45, 16 September 2016 (UTC)

I tried that on a preview of this Superellipse page and I could not see the rendered math even with no spaces whatsoever in the math markup. But if it makes you happy, go delete some of those spaces... --Rdm (talk) 14:49, 16 September 2016 (UTC)

I did some cursory (and somewhat shallow) web searching for problems with Chrome, LaTeX rendering --- particularly the   <math>   blank/empty rendering, and other such symptoms.   There are this and other problems that have been introduced with a new(er) version of Chrome, some have a work-a-round, but the problems are being addressed (as far as I can glean from the various articles), and, if indeed, the symptoms being seen are manifestations of the same problem(s).   I uninstalled Chrome many ages ago when I had similar problems with it's (bad) rendering of various texts and especially some fonts.   This latest go-around (here at Rosetta Code) seems to be focused on the "flanking" whitespace and the reversion of changes, and the describing of the symptom of the problem as making the formulae invisible (or more descriptive, the rendering of blanks).   Some of the changes being reverted have been around for months, leading me to believe that the problem probably lies with the recent changes to Chrome   (and I presume, Safari).   I wonder if the mere act of reverting the Rosetta Code pages to an earlier text bypassed   (in and of itself)   the problem in the newer version of Chrome?   I've asked Mr. Hout previously if he reported the problem to Chrome and/or Safari peoples to have this particular problem addressed, and I also requested a bug or tracking number to follow this problem's resolution   (nothing replied so far).   If Chrome (and/or Safari) doesn't render the LaTeX (or whatever) correctly, maybe the Rosetta Code users of those browsers might be better served if they used FireFox   (or any other browser that works)   until the problem gets fixed by the code writers of those failing/broken browsers.   -- Gerard Schildberger (talk) 17:55, 16 September 2016 (UTC)

Eyebrows duly raised :-) But never mind, as long as you do now know that introducing redundant flanking space will hide previously visible formulae from unfortunate users, and as long as you quietly check the consequences of your edits with editors who have macs (Rdm for example ?), those of use who are affected can shoulder the restoration of visibility whenever it has been lost. As for your robust expressions of confidence that the problem lies with the browsers, well, I think we both know that neither of us knows enough to be very confident of that, either way.

What we do now know is that the recent decline in the visibility of formulae on OS X can be easily reversed, by reversing a small aspect of your otherwise very helpful edits. Hout (talk) 19:07, 16 September 2016 (UTC)

There is no evidence that the problem lies with Safari and Chrome, and the likelihood of two entirely separate engines having simultaneously acquired identical bugs seems a little too low to really detain us for long :-) The visibility problems are not new. If you really wanted to understand what was going on, you would need to make a careful study of the output of the Wiki software's preprocessor. In the meanwhile, you can retain the value of your edits (changes in visible spacing and font sizing), and remove the damage inadvertently done to visibility in OSX Safari and Chrome (not just recent versions) by reverting the state of the math tag contents alone. There is no dishonour in having unwittingly created a problem - though it might raise an eyebrow or two if you were to resist the repair :-) Hout (talk) 18:19, 16 September 2016 (UTC)

Safari and Chrome are not two entirely separate engines;   WebKit is an open source browser engine for rendering web pages that is used in Safari and it had been used in Chrome, but Google currently incorporates (I don't know the date) a WebKit fork/offshoot of WebKit with software named "Blink", so there is some commonality of code, of which and how much, I do not know.   I don't know enough about Wiki's software pre-processor or even where to find/view the output of same, let alone make a careful study of its output, nor would I suggest that someone study that as a means of resolving a problem (or trying to find out the location of where the problem is).   That is way beyond my capabilities and time availabilities.   Since I don't see the non-rendering (the "invisibility" that you see) with the web-browsers that I have installed), it wouldn't behoove me or Rosetta Code to make further changes in removing whitespace in specific areas as I can't see the results (the failures) that you're seeing with your browsers).   I don't believe that I introduced (even unwittingly) a problem, but as I see it, you most likely have uncovered a problem in the way LaTeX is rendering whitespace in the browser(s) that you're using.   I'll never accuse anyone of introducing a problem just because my browser fails in handling (rendering) whitespace.   I've been web-searching for Chrome's (rendering of LaTeX and other stuff) problems, and there seems to be enough discussion on issues related to these types of issues.   -- Gerard Schildberger (talk) 18:53, 16 September 2016 (UTC)

That evidence might be inadequate, or not conclusive, and maybe even superficial, but it's not zero, either. Meanwhile, the mechanism for working around the problem (adding space or deleting space and - generally speaking - reverting to older versions) seems ad hoc (which probably means we do not understand what is going on well enough to be drawing conclusions yet).

That said, I do not see any problem, yet, with using this ad-hoc mechanism to fix the rendering of math markup. If it was breaking something else significant, though, let's hear about that.

I should add that I see this problem with safari version 8.0.8, so it's apparently a long-standing issue. (Which should not be surprising. I saw work happening on a different browser bug something over ten years after I reported the problem.) --Rdm (talk) 19:00, 16 September 2016 (UTC)

Thanks. Restoring the formula code to the pre June 4 version has restored its visibility here. Are you seeing the same ? Hout (talk) 15:19, 16 September 2016 (UTC)

It does work for me, now, also. --Rdm (talk) 15:22, 16 September 2016 (UTC)

Toggling flanking space now proves sufficient to toggle formula visibility in OSX Chrome and Safari, but it looks as if some of Gerard's other spacing edits can also suppress visibility in the same contexts. In short, lost formula visibility can more consistently be restored by simply reverting the contents of the math tags to their state on the last date before the TOC spacing edits were undertaken. Hout (talk) 16:33, 16 September 2016 (UTC)

I don't understand what you mean by "looks like".   It either does or doesn't.   Could you be more specific what those contexts are before you lay blame on "other spacing edits"?   I don't understand what TOC spacing has to do with this.   I've been adding whitespace before the TOC for over a year and a half now.   In a recent change, both whitespace and the use of a bigger font via   <big>   were reverted.   It can't be symptomatic that both would be causing the problem(s).   -- Gerard Schildberger (talk) 17:55, 16 September 2016 (UTC)

It does. Visibility is restored in most cases by simply deleting the flanking spaces which you introduced, but in other cases this does not prove sufficient. It does, however, prove sufficient to revert the context of the Math tags to the state they were in before you undertook the edits. I don't know how many other tasks are affected – I just noticed the same problem with Binomial Coefficients, but it's certainly possible that a trail of formulae have been losing their visibility to some users for over a year now. I have been aware of the patchy visibility, and had a sense that invisibility was a growing problem, but I hadn't previously taken the time to pin it down. Hout (talk) 18:04, 16 September 2016 (UTC)

You should be able to identify what other elements of your edits are toggling formula visibility by a process of elimination.

Er, no.   If I saw that any of my changes toggled (or caused) the wrong/incorrect rendering (or as you say, invisibility), I wouldn't have done the changes in the first place.   None of my changes (edits) caused incorrect rendering on the browsers that I use.   -- Gerard Schildberger (talk) 19:31, 16 September 2016 (UTC)

Introducing the the HTML entity &nbsp; seems like one candidate that might be worth checking. The broader picture is, however, clear - visibility is always restored by reverting your spacing edits en masse, and is usually, but not always, restored by only reverting the flanking spaces in math tags. Experiment is the only source of knowledge, and even then Nature reveals her secrets reluctantly :-) Hout (talk) 18:43, 16 September 2016 (UTC)

Another solution ... visibility is always restored by using FireFox (and/or other browsers including Microsoft Internet Explorer).   I'm not suggesting that's the way to go, but I'd rather use a browser that works consistently than to one that mostly works, and then starts to fail (in a somewhat "quiet"/non-visible way).   I don't have a dog in the browser fights, I generally stick to what I know works, even though there must be varied advantages (and varied shortcomings) for each browser.   I have no idea which version of Chrome and/or Safari (or something else) you're using, what operating system is being used, 32-bit vs. 64-bit version, etc.   I read that Chrome 19 fixed some of these problems.   -- Gerard Schildberger (talk) 19:31, 16 September 2016 (UTC)

Chrome 53.0.2785.113 (64-bit) has these problems... --Rdm (talk) 19:34, 16 September 2016 (UTC)

The bug is, as theory might have predicted, not in the browsers. It turns out to be in the wiki preprocessor, which for some reason generates an ill-formed image placement tag if redundant flanking spaces are inserted into math tags. See: http://rosettacode.org/wiki/User_talk:Rdm#.22math.22_HTML_tag_not_rendering_properly Hout (talk) 22:47, 16 September 2016 (UTC)

In general, browsers are supposed to ignore syntactically incorrect html. I suppose though there might be an argument whether in this case it is the entire style attribute which is syntactically incorrect because of the missing semicolon in the value or whether it is the vertical-align element which is syntactically incorrect or whether it should be the part of the style attribute from the vertical-align element to the end of the style.

Worse than that, though, since this behavior is OS specific, it is not clear whether it is even browser code which is relevant.

Anyways, I guess my point is that we have multiple issues occurring here, which makes it problematic to talk about "the" bug.

That said, what do we have to do, to fix the wiki preprocessor, to not omit that semicolon? I see several tex preprocessors listed at https://www.mediawiki.org/wiki/Alternative_parsers but I do not know enough about mediawiki to know which of those we are using... --Rdm (talk) 02:21, 17 September 2016 (UTC)

Hells bells, I didn't even know there was a Wiki pre-processor.   I was surprised on how many there are, and also that so many of them are apparently supported by only one person instead of a team.   I wonder how many of those pre-processors listed   don't   have this particular "bug".   -- Gerard Schildberger (talk) 03:09, 17 September 2016 (UTC)

The generator is announced, in the HTML created by Rosetta, as MediaWiki 1.26.2, and it looks to me as if that implies the use of https://www.mediawiki.org/wiki/Extension:Math, which does provide contact details.

We don't know that the behaviour is OS-specific. It does, however, depend on whether a given browser processes MathML directly (not a standard technology, and only supported within browser companies by volunteer-work, according to Wikipedia) or uses the more reliable fall-back of displaying a graphic file. On OS X for example, Firefox is using MathML to get a formula onto the screen, whereas Chrome and Safari take the route of displaying the fall-back graphic file, but are prevented from doing so by the unparseable HTML code which we have been serving up with increasing regularity, as the missing semi-colon spreads doggedly through our Task pages.

It's not spreading (doggedly or otherwise), it's already there in the sense the whitespace is already there.   -- Gerard Schildberger (talk) 06:31, 17 September 2016 (UTC)

Syntactically incorrect HTML is certainly a bug from a browsers point of view, but we may find that the authors of the https://www.mediawiki.org/wiki/Extension:Math throw up their hands and ask us why on earth we thought that they supported the insertion of redundant white space literals around our Latex expressions :-) Hout (talk) 05:26, 17 September 2016 (UTC)

That should be an easy question to answer. Consider, for example: https://www.sharelatex.com/learn/Spacing_in_math_mode --Rdm (talk) 07:47, 17 September 2016 (UTC)

In all the bugs that I've reported (mostly to IBM and compiler developers) over my many years, I have never had authors (or code supporters) ask me why a program (or person) was using a legal construct (as if that's an excuse why whitespace was being used somewhere for readability).   You have found that the browser is getting syntactically incorrect HTML code from a Wiki pre-processor, and the reason why that is being constructed incorrectly for some pre-processor seems to be now known (a missing semicolon).   Also keep in mind that not all browsers (or pre-processors?) are failing.   Apparently, not all Rosetta Code people are using the same Rosetta Code (Wiki) pre-processor, is that correct?   If I reported a problem with (say) a compiler [or whatever] which caused it to fail with inserted extra (or redundant) whitespace (where it isn't specifically barred), the failing/incorrect code gets fixed.   Why should they care if whitespace is redundant or not?   Redundancy for whitespace is almost in the definition of whitespace.   -- Gerard Schildberger (talk) 06:31, 17 September 2016 (UTC)

"hell's bells I didn't even know there was a pre-processor" is an entirely understandable defence from our end, but It may feel slightly galling to them ... Hout (talk) 05:36, 17 September 2016 (UTC)

I'm not stating or supplying a defense in any way, just an admission of ignorance.   You seem to be confused at the reason of my statement, and it was not intended to be used as an excuse to (or for) anybody, let alone the people to whom I'm not in contact with.   I certainly can't/won't speak to how they would respond or feel (with or without gall).   -- Gerard Schildberger (talk) 06:31, 17 September 2016 (UTC)

Gerard wrote > Apparently, not all Rosetta Code people are using the same Rosetta Code (Wiki) pre-processor, is that correct?

No, that's not correct. All the code generation, for every single Rosetta user, is done by the same processor, on the Rosetta server - it's not a client-side process, or a client-side option.

Every single Rosetta user is being served ill-formed tags for the graphic file version of formulae in tasks where you have made the spacing edit, and wherever else the MediaWiki 1.26.2 processor (HTML code generator) is choking on any other unexpected input of this kind.

The only variation between users is that some are using browsers which happen not to need that graphic file, because they have full support for rendering the MathML version directly. Unfortunately full MathML support is only at about 25% http://caniuse.com/#feat=mathml most browsers depend on the graphic file route, which is blocked as soon as that semi-colon is lost. (One of the reasons for limited adoption of MathML by browser producers seems to be a dependence on the installation of requisite fonts).

That would explain why my browser doesn't show some of the more eclectic fonts used on Rosetta Code, such as the Unicode chess pieces glyphs (and among other glyphs).   I always wondered why other Rosetta Code users could see those glyphs rendered, but my browsers didn't, even though, at the time, it was the latest (Beta) version. -- Gerard Schildberger (talk) 19:39, 17 September 2016 (UTC)

It was understandably not obvious to you that you were leaving a trail of invisible formulae behind you - you are clearly using one of the browsers which do not need the graphic file because they are rendering from the MathML.

Yuppers, you're the first person to acknowledge that I didn't have the other tools installed (failing browsers) to view the problem (of "invisibility"),   all I viewed (via my two browsers) was what I was expecting and observing:   the correct rendering(s) of   <math> ∙∙∙ </math>   text.   -- Gerard Schildberger (talk) 19:39, 17 September 2016 (UTC)

I am little puzzled that you persist in speaking hopefully of "failing browsers" :-) No browsers are failing - they are behaving correctly. The mediaWiki software had been generating syntactically correct tags for the display of formula graphic files, but was no longer doing so after your edits, rendering the formulae invisible (yes, invisible, no need for quotes :-) to all browsers (the majority) which use the graphic file for the display of formulae. Have you heard of a large river which flows through Egypt ? Hout (talk) 19:48, 17 September 2016 (UTC)

Mr Hout:   I was speaking of the browsers that are failing to render the text, whether it be from ill-formed HTML code or whatever reason, I wasn't laying blame on (or to) the browsers.   I also was using the word "invisible" (in quotes) as that was the word you introduced.   The word "invisible" suggest that the formula is there, but just can't be seen.   In fact, the formulae aren't invisible, they just aren't being rendered (in the failing case), and that is why I placed the word invisible in quotes.   There isn't any need to use such language (and interpreting my statements as being hopefully this or that ...),   this isn't helping in solving and trying to address problem resolution, and reverting to ad hominem statements and snide criticisms like the above aren't in the spirit of Rosetta Code.   Lets try to be more civil in these public forums.   -- Gerard Schildberger (talk) 20:23, 17 September 2016 (UTC)

A suggestion, install a second browser on your system - one of the major ones which displays the graphic file rather than a local MathML render, (possibly Chrome ? not sure which platform you are on ...) and start restoring visibility to any remaining formulae which you inadvertently rendered invisible on most browsers.

That will also enable to you check that you are not further damaging the visibility of formulae in any other edits which you undertake, and may give you a little more insight into the expectations and outputs of the MediaWiki processor. Good luck, and happy repairs ! Hout (talk)

I already have a second (and a few other older ones) on my system.   I already explained earlier and elsewhere, that isn't possible to do any major upgrades with my current system.   The FireFox browser was addressing needs and concerns that the other browsers weren't.   I guess FireFox and Microsoft's Internet Explorer aren't giving me enough insights to the Wiki pre-processor, especially since I didn't even know that the pre-processor existed before this all happened!.   If the pre-processor correctly handled that (missing) semi-colon, I (and a bunch of others) would still be unaware of it.   -- Gerard Schildberger (talk) 21:28, 17 September 2016 (UTC)

Gerard wrote: "I guess FireFox and Microsoft's Internet Explorer aren't giving me enough insights to the Wiki pre-processor". Checking with your copy of Internet Explorer would have given you that insight if you had tried. IE is a member of the majority browser class - one of those which displays the server side graphic file for the formula. If you had used it to check your edits, you would have seen immediately that they were preventing the display of that graphic file.

It's very important to check the real effects of formula edits on both browser types, and particularly on the majority type. Hout (talk) 18:04, 26 September 2016 (UTC)

Fair enough - but probably prudent, then, to suspend the cosmetic enhancement drive until you are equipped to check whether or not particular edits are eliminating legibility, rather than enhancing it, for the majority of browsers Hout (talk) 14:53, 18 September 2016 (UTC)