Anonymous user
User talk:Rdm: Difference between revisions
m
→fixing "language" entries so that they appear as languages: added a new talk topic.
m (/* Bug found in wiki-preprocessor - image metatag placement attributes corrupted when flanking spaces are introduced into Math tag) |
m (→fixing "language" entries so that they appear as languages: added a new talk topic.) |
||
| (44 intermediate revisions by 3 users not shown) | |||
Line 287:
=="math" HTML tag not rendering properly==
:'''TL DR;''' This is now diagnosed, but not yet everywhere repaired, at the time of writing. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 19:05, 20 September 2016 (UTC)
:: The subset of browsers which display the 'fallback' graphic file, rather than locally processing MathML code (the majority of browsers, in fact) are prevented from displaying the formula graphic by a piece of syntactically ill-formed HTML which can be generated, in response to certain unexpected inputs, by the MediaWiki 1.26.2 processor.
:: One of the unexpected inputs, introduced to a largish number of task pages over recent months by a well-intentioned program of editorial tidying, simply consists of <math> tags to which redundant white spaces have been added, either before or after the Latex content.
:: The point to be aware of is that in Rosetta pages, we are not editing actual HTML <math> tags, but rather '''MediaWiki input <math> tags''', which are translated into their HTML counterparts by the MediaWiki processor. It is therefore important to be aware of the behaviour, and the input expectations, of the MediaWiki processor itself.
:: It is also important to check the real effects of any edits which we make on both kinds of browser - the majority, like Chrome and Safari, that display the graphic file, and the minority, like Firefox, that generate an image by local processing of MathML code, and depend on the local installation of requisite fonts. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 19:05, 20 September 2016 (UTC)
At least two people (Rosetta Code users),
Line 323 ⟶ 329:
::: Ah - getting clearer now, on closer reading of the diff.
::: It looks as if the injection of the fallback '''alttext''' attribute is prompted by some kind of error condition, and is not itself the source of a failure to display.
::: The deeper problem is that when the redundant flanking spaces are introduced into the math tag by a human editor, a bug in the wiki preprocessor generates some '''ill-formed HTML code''', dropping a semicolon at the end of a vertical-align attribute and concatenating the alignment value straight into the name of the following height attribute, so that we get something like: '''vertical-align:-2.671exheight''' where there should be a semi-colon between the letters '''x''' and '''h'''.
::: Restoring the missing semi-colon between the '''vertical-align''' and '''height
::: In short - there is a bug in the wiki pre-processor. Adding the redundant spaces to a math tag leads to the generation of an ill-formed fall-back image metatag, with a corrupted pair of placement attributes. Not a bad reason for scrupulously avoiding the injection of redundant space into <math> tags, and clearly no fault of the browsers. Bug report, some one ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 22:39, 16 September 2016 (UTC)
:::: Thank you for your efforts to locate where the problem lies. What I don't understand why it works for FireFox and Microsoft Internet Explorer, and not the iOS and OS X browsers? Shouldn't it be failing on all web browsers? (I'm not quite sure where the Wiki pre-processor "fits in" with the browsers. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 22:50, 16 September 2016 (UTC)
::::: The pre-processor doesn't "fit in" with the browsers, it simply generates the HTML code which they all read. Browser behaviour with '''syntactically ill-formed code''' is undefined. One could even argue that the Chrome and Safari non-display of an image placement tag with corrupted placement attributes is more "correct" than the Firefox response of concealing the problem and making a guess. Both approaches are understandable. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 22:56, 16 September 2016 (UTC)
:::::: Since it is now known that "flanked whitespace" causes ill-formed code in the Wiki pre-processor being used on Rosetta Code, then why don't those whitespace(s) be (solely/only) removed, and not change (remove) the use of larger fonts (larger fonts [using the BIG HTML tag] makes the formulae easier to read). Easier to read/peruse formulae was the whole intent of the changes in the first place. The baby is being thrown out with the bathwater. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 19:54, 17 September 2016 (UTC)
::::::: In most cases removing the flanking white space which you introduced proves sufficient to allow the MediaWiki processor to start generating syntactically correct code again. In some cases it does not prove sufficient to do that, but reverting the code to the state in was in before your edit '''does''' prove sufficient. More diagnostic work would doubtless reveal exactly what other aspects of your changes have proved unexpected or indigestible to the MediaWiki process, but all the work of diagnosing the problem, restoring visibility to these formulae, and, most time-consuming and exhausting of all, gradually overcoming your puzzling personal reluctance to accept and understand what has been happening, has already cost me more time than I can afford. It may be that in some cases the processor is unable to generate a graphic file as large as your double "big" tags are requesting, in the space in that it calculates to be available.
Mr Hout: You needn't worry about my supposedly reluctance to accept what has been happening. You are assuming and/or interpreting wrongly (of my beliefs of what has been happening), and most of your assumptions are wrong concerning my knowledge and acceptance of what's occurred to cause the failure. I've learned what is triggering the failure in the Wiki pre-processor and how it causes some browsers to not render the formulae. Your personal snipes about my supposedly puzzling over whatever doesn't need to be voiced, it is wrong to assume that, and also wrong to voice it in such a way that it seems that my reluctance is the cause if your more wasted time. If it's important for you to know what I know or accept, then ask me directly instead of wrongly interpreting what I believe. You're not overcoming my reluctance, I've already understand the problem, and I learned more from Rdm's statements and thoughtful wording of the problem. I also understand that it is important for people to view the formulae, and by the removing of whitespace, this will cause (or should cause) the correct rendering of the formulae. Whether or not you believe I understand the problem or not shouldn't effect fixing the problem (or implementing a work-around). I don't see the need for voicing such negative and inappropriate (and incorrect judgements) concerns about my intentions or beliefs. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 21:16, 17 September 2016 (UTC)
::::::: In short, I am doing the only the minimum required to restore the visibility to fomulae unintentionally hidden by your edits. I quite understand that it must be distressing to see some part of your work undone. I hope you can make the effort to understand that it might also be distressing to see the formulae vanishing entirely ... [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 20:12, 17 September 2016 (UTC)
:::::::: No, you're wrong about my distress. I do not see it that way at all, the underlying problem should be fixed, or at least in the meantime, have the rendering of the formulae changed so as to be seen/viewed by everyone. Nothing is being undone (externally), the formulae are being edited/changed so they can be rendered for all browsers. Please don't ascribe/assume feelings to me that aren't accurate or presumptive. This only detracts from the civility here on Rosetta Code and clutters up the discourse. I don't have to make an effort, I already understand the need to make the changes (quickly) so that the formulae don't vanish entirely. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 21:16, 17 September 2016 (UTC)
:::::::: If anyone else would like to take a turn and try the experiment with these repairs - look at Heronian Triangles. Gerard's edits have inadvertently rendered the formulae on that task page invisible to browsers which display the graphic file, and it is one of the cases where just removing the flanking white spaces which Gerard introduced inside Math tags does not prove enough, but reverting the formula code entirely to the state it was in before his edits does prove enough to restore visibility [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 20:25, 17 September 2016 (UTC)
<hr>
This isn't the only bug that exists (at least, as far as rendering HTML code). I know of four others that would fall in the "flaky" category, as one widens the window, or contracts it, "things" disappear or re-appear (mostly the top or bottom of a "box", or internal lines of a grid (table), so I had suspected a browser problem or perhaps an operating system (Microsoft Windows in my case), but I didn't have the knowledge or tools to diagnose it and/or pursue problem resolution. One such problem I observed around three or four (?) years ago in rendering a vinculum (for a square root glyph), it worked on FireFox, but not Microsoft Internet Explorer. It turned out that MS' I.E. rendered some text wider, and FireFox didn't, so it showed on one browser, but not the other, but it was mainly due to the fact that, at that time, I had a really wide high-resolution monitor, and something was tripping (apparently) probably on the same problem that is now being observed. To make the problem resolution a wee bit more complicated, I had dual (identical) monitors, each monitor had a different browser (and driver protocol), so I thought it might be a monitor or driver problem. That particular problem was really driving me batty (costing me more than a few number of hours), ... it was there, made a small change, next time ... it wasn't. The small (benign) change could be just changing my socks. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 23:13, 16 September 2016 (UTC)
<hr>
Rdm: I finally --- (after dealing with myself being mostly bed-ridden and I'm more or less restricted to sitting up for short periods, so I'll try to make this brief) --- got my (Windows/XP) system somewhat repaired (I think) and I can now post thingys to Rosetta Code via FireFox (Aurora), but my Microsoft Windows Internet Explorer (version 8) is still flaky and can't open most webpages.
After doing some rather vague (Google) searches, I finally found something that touches on this problem (on Rosetta Code) and apparently solves the underlying problem, but I have no idea if that "patch" applies to any software that Rosetta Code is utilizing. That bug/problem (below) started occurring (elsewhere) on or before April 12th, 2016.
The circumstances that caused the missing semicolon was not mentioned, however.
The fix is referenced on: https://gerrit.wikimedia.org/r/#/c/283166/
Here is an excerpt:
Change 283166 - Merged
Ensure use of ; to seperate (sic) svg styles It was reported that under certain
circumstances a semicolon was missing from the SVG style.
Bug: T132563
Change-Id: I148433657848fdc74889fcaf6d883078c46a4006
Here is a description of the bug:
<pre>
I believe there is a bug in the way the SVG fallback image HTML code is generated when
using MathML + SVG fallback and a Mathoid server.
Here is the HTML code that I obtain for an SVG fallback image:
<meta class="mwe-math-fallback-image-inline" aria-hidden="true" style="background-image: url('/wiki/index.php?title=Special:MathShowImage&hash=2caf40baf06d5cb633d350e651164506&mode=mathml'); background-repeat: no-repeat; background-size: 100% 100%; vertical-align:-2.338exheight: 6.176ex; width: 24.761ex;" />
There is a missing semicolon between vertical-align:-2.338ex and height: 6.176ex, and
that causes the SVG image not to display on the page.
The problem appears to come from the function correctSvgStyle( &$style ) in MathMathML.php.
I could fix the bug by changing the line
$style .= ' ' . $styles[1]; // merge styles
into
$style .= ' ' . $styles[1] . ';'; // merge styles
</pre>
Elsewhere, it was said:
<pre>
Such a picture has zero height and thus is invisible (in chrome).
</pre>
This is, as the saying goes, way over my pay-grade. I have no idea even where the fix goes (to be applied), nor if that fix is applicable to the software on Rosetta Code.
But it sure seems to address the issue of the missing semicolon in the SVG style. It was said elsewhere on Rosetta Code that the Wiki pre-processor is slightly back-level. Maybe updating that piece of software may already have such a fix already applied?
But, in any case, I assume you know who to contact (in Rosetta Code land) and see if this fix/patch is applicable or even applies. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 21:33, 25 September 2016 (UTC)
: The real underlying problem is that two different formula display methods are used by current browsers, and that these are served by two different parts of the generated code.
: Even if, as we hope, this particular fragility happens to get fixed at some point, it will remain unsafe and imprudent to make formula edits in one class of browser without checking their real effects in the other. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 22:03, 25 September 2016 (UTC)
== Sieve of Eratosthenes ==
Line 332 ⟶ 413:
: Thank you. Fixed. (Or, at least in principle - I am currently waiting for the edited page to show up.) --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 16:07, 27 July 2016 (UTC)
==Tasks still affected by MediaWiki <math> tag issue as of Sept 21 2016==
The following 54 Rosetta task wiki pages still generate ill-formed HTML which prevents display of graphic (usually formula-displaying) files. Most, but not all, of these arise from a recent program of cosmetic edits in which redundant white spaces were were introduced into <math> tags, and these were flanked by a pair of <big> tags. It was not appreciated by the editor involved that the MediaWiki processor did not anticipate or properly handle some of the input patterns that were introduced, and their effects were, unfortunately, only tested on a minority type of browser which does not use graphic file display for formulae. The fact that formula after formula was being left completely invisible to most browsers took several months to sink in and be properly understood.
In a number of tasks the edits have now been reversed and formula visibility restored, 54 remain unfixed.
===Names of tasks still affected===
: "A+B" (now fixed – [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 08:23, 22 September 2016 (UTC))
: "Ackermann_function"
: "AKS_test_for_primes"
: "Amicable_pairs"
: "Arbitrary-precision_integers_(included)"
: "Arithmetic-geometric_mean"
: "Benford's_law"
: "Carmichael_3_strong_pseudoprimes" (now repaired – [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 09:50, 22 September 2016 (UTC))
: "Casting_out_nines"
: "Check_Machin-like_formulas"
: "Chinese_remainder_theorem"
: "Conjugate_transpose"
: "Constrained_random_points_on_a_circle"
: "Deal_cards_for_FreeCell"
: "Display_a_linear_combination"
: "Egyptian_fractions"
: "Elliptic_curve_arithmetic"
: "Equilibrium_index"
: "Euler_method"
: "Farey_sequence"
: "Faulhaber's_formula"
: "Fractran"
: "Gamma_function"
: "Hash_join" (now fixed – [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 19:42, 22 September 2016 (UTC))
: "Heronian_triangles"
: "Hofstadter_Figure-Figure_sequences"
: "Hofstadter_Q_sequence"
: "Identity_matrix"
: "Integer_roots" (now fixed – [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 08:29, 22 September 2016 (UTC))
: "Jaro_distance" (now fixed – [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 20:02, 22 September 2016 (UTC))
: "Josephus_problem" (Repaired ---[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 15:30, 28 October 2016 (UTC))
: "Knuth_shuffle"
: "Least_common_multiple"
: "Ludic_numbers" (now repaired – [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 21:08, 22 September 2016 (UTC))
: "Modular_exponentiation"
: "Modular_inverse"
: "Monte_Carlo_methods"
: "Multifactorial"
: "Multiple_regression" (now repaired – [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 21:23, 22 September 2016 (UTC))
: "Nth_root"
: "Permutations_with_repetitions" (now fixed – [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 08:26, 22 September 2016 (UTC))
: "Pi" (now repaired – [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 21:33, 22 September 2016 (UTC))
: "Pythagorean_triples"
: "Quaternion_type"
: "Real_constants_and_functions"
: "Runge-Kutta_method"
: "Sattolo_cycle"
: "Shortest_common_supersequence"
: "Subtractive_generator"
: "Sum_of_a_series"
: "Sutherland-Hodgman_polygon_clipping"
: "Test_integerness"
: "Thiele's_interpolation_formula"
: "Trabb_Pardo–Knuth_algorithm"
: The list is generated by searching through the task HTML for the pathological string '''exheight''', which arises when a semicolon is missing between a vertical-align attribute and a height attribute. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 20:17, 21 September 2016 (UTC)
:: There is a full list of repairs so far (I am aiming to update it weekly), at http://rosettacode.org/wiki/User_talk:Gerard_Schildberger#Restoring_formula_visibility_to_50.2B_tasks_for_Chrome.2C_IE.2FEdge.2C_Safari_etc
:: As of today, we are down to 34 tasks whose visibility to most browsers has yet to be restored. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 18:16, 28 October 2016 (UTC)
==Upgrading generator to MediaWiki 1.27 ?==
In case this is not already in hand, I notice that Rosetta pages are currently generated by
<meta name="generator" content="MediaWiki 1.26.2"/>
and that 1.27 is available at https://www.mediawiki.org/wiki/Special:ExtensionDistributor/Math
Discussion here:
https://phabricator.wikimedia.org/T136089
suggests that 1.27 might alleviate the problem of formula images made invisible (zero height) when a semicolon is lost between two attributes: [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 21:41, 25 September 2016 (UTC)
: Caveat: I saw and fixed a similar problem yesterday on Wikipedia (redundant space in <math> tag triggering the same loss of semicolon and visibility), despite the fact that Wikipedia is using a later build of the generator. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 21:52, 25 September 2016 (UTC)
==fixing "language" entries so that they appear as languages==
I noticed that some language entries (perhaps improperly configured or wrongly set-up or other) are not appearing at "languages" (in the ''Category:Programming Languages'' page). Lately, I noticed another: '''Shapely'''.
Undoubtedly, there are others (and I now regret not writing them down in a list of some sort).
I think it seems/appears to have the #REDIRECT thingy "backwards".
I have in the past fixed a number of them, but I am now reluctant to fix such errors at this point. Some of these improperly set-up languages are a bit beyond what I know about how to fix such things. Perhaps you could fix and/or address these one (that I know of) language (definition) entry such that it appears where it ought to appear. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 09:23, 26 March 2020 (UTC)
| |||