4
$\begingroup$

In this comment, the penultimate number in the list, $59930$, is displayed (in Firefox $11.0$) with a spurious space between the two $9$s. I made sure I hadn't inadvertently pasted any invisible spaces in the input by selecting the $9$s and overwriting them with two consecutive $9$s typed on the keyboard.

$\endgroup$
34
  • $\begingroup$ There is a non-display character between the two 9s. If you copy/paste into a text file it will become apparent. $\endgroup$
    – Peter Phipps
    Apr 12, 2012 at 9:58
  • 2
    $\begingroup$ @Peter: I'm aware that there is one in the output; that's precisely the problem. What I was saying was that I made sure there wasn't one in the input, so there shouldn't be one in the output. $\endgroup$
    – joriki
    Apr 12, 2012 at 10:00
  • $\begingroup$ @joriki, I did the following experiment. I copied the number from your comment, and pasted it into an empty comment box. It displays the 5 digits without any extra space. But suprisingly it also tells that only '8 more to go'. As the minimum number of characters is 15, I became suspicious. When I went to the end, and started deleting the characters one at a time, the number or required characters started going up (as predicted), '9 more to go', 10, 11, ... at which point the counter was still going up, but the cursor stopped moving. There are still two extra characters between the 9s. $\endgroup$
    – Jyrki Lahtonen
    Apr 12, 2012 at 10:29
  • $\begingroup$ @Jyrki: You found what Peter found, that there's an extra character in the output. As I replied to Peter, not only am I not denying that, that is in fact the problem. There shouldn't be one because I made double sure that there wasn't one in the input (which you can't check, of course, which is why I made sure that I checked it). (By the way, I find only one, not two invisible spaces in the output when I copy and paste it.) $\endgroup$
    – joriki
    Apr 12, 2012 at 10:40
  • $\begingroup$ This may not be entirely accurate, but probably related: I think that the MathJaX parser breaks the code into pieces of at most 79 characters that will then be processed. If you look at this deleted piece of silliness example 2 breaks at the \b of \bigvee (and it looks like \b is interpreted as a LaTeX command in itself); the b is the 79th character that was entered without blank space with no possible break point before. If you insert a blank between a comma and a number before the 79th place in your example, the spurious space disappears. $\endgroup$
    – t.b.
    Apr 12, 2012 at 11:09
  • $\begingroup$ Yeah, Peter must have seen the same thing. I do get two extra characters. Both in an empty comment box, and also when I paste it into a text editor. $\endgroup$
    – Jyrki Lahtonen
    Apr 12, 2012 at 11:11
  • $\begingroup$ In the source code of the page with your comment my browser has 9‌​9 where the two nines are separated, so two null character entities. $\endgroup$
    – t.b.
    Apr 12, 2012 at 11:18
  • $\begingroup$ @t.b.: I see -- that's rather bad, and a lot more general than my case. By the way, glad to see you're back :-) (in case my impression that I'd seen you around less for a while had been right). $\endgroup$
    – joriki
    Apr 12, 2012 at 11:51
  • $\begingroup$ Thanks! :)${}{}{}{}$ $\endgroup$
    – t.b.
    Apr 12, 2012 at 15:18
  • 1
    $\begingroup$ @joriki: I see the same &zwnj;&#8203; characters in the page source. The first is a "zero-width non-joiner" (though I don't really understand what that means), and the second is a "zero-width space". MathJax does not think of these as belonging within a number, so make the 59 into one number and 930 into another, with two <mo> elements in between (in the internal MathML representation), each containing a zero-width character. Those <mo> elements get a little space around them by default, which is where your space is coming from. $\endgroup$
    – Davide Cervone
    Apr 12, 2012 at 22:37
  • $\begingroup$ If you didn't add the &zwnj;&#8203; entities yourself, then perhaps it is your editor that is doing it. Are you editing your responses elsewhere and pasting them in, or are you using the SE editor directly? $\endgroup$
    – Davide Cervone
    Apr 12, 2012 at 22:38
  • $\begingroup$ &t.b.: you suggest that MathJax is breaking the input at 79 characters, but that is not the case. I was not able to find the \bigvee on the page you indicated, so I can't check what is going on there, but MathJax has no trouble parsing data that is longer than 79 characters. I suspect it must be earlier in the pipeline (like perhaps the editor) that is causing the problem. $\endgroup$
    – Davide Cervone
    Apr 12, 2012 at 22:40
  • $\begingroup$ @Davide: I produced these numbers as output from a Java program, which I copied and pasted into the comment box. Although there's no reason for that to contain invisible spaces in the middle of a number, when I saw the spurious space, I edited the comment and, as described in the post, selected the two $9$s and typed two consecutive $9$s on the keyboard directly into the comment editor to make sure that there was nothing invisible between those two $9$s in my input. I'll add another comment here where I type the entire text by hand just to make sure. $\endgroup$
    – joriki
    Apr 12, 2012 at 23:04
  • $\begingroup$ first try (with copy and paste) $1,2,2,9,2,46,2,250,37,254,2,31052,2,1480,896,306174,2,2097506,2,6025516,6638,59930,2$ $\endgroup$
    – joriki
    Apr 12, 2012 at 23:05
  • 1
    $\begingroup$ @joriki: I mentioned in an earlier comment why the zero-space characters end up produce space. They characters themselves are typeset as zero-space characters by MathJax, but they are put in <mo> elements in the MathML that MathJax generates, and by default, <mp> elements have some space on both sides of them. That is the space you are seeing. It would be possible to modify what MathJax thinks is allowed as part of a single number to include these characters, but I'm not sure if that is the right thing to do or not. $\endgroup$
    – Davide Cervone
    Apr 13, 2012 at 12:38

2 Answers 2

Reset to default
10
$\begingroup$

The Problem:

In a comment to a question or an answer, or on chat, when a string of over 80 characters is entered without whitespace, the pair of characters \unicode{x200C} (zero-width non-joiner) and \unicode{x200B} (zero-width space) is inserted after 80 characters. This is often bad when it happens in $\LaTeX$ source.

In the comment in question, the following 86 character string appears:

$1,2,2,9,2,46,2,250,37,254,2,31052,2,1480,896,306174,2,2097506,2,6025516,6638,59930,2$

The pair of characters mentioned is inserted after character 80, splitting 59930 into 59 and 930.

A Workaround:

There is a fairly simple workaround: insert a whitespace character, if possible, where it will have no effect. For example, just before the 59930:

$1,2,2,9,2,46,2,250,37,254,2,31052,2,1480,896,306174,2,2097506,2,6025516,6638, 59930,2$
$\endgroup$
4
  • $\begingroup$ I guess it is Markdown that is inserting the characters? Certainly adding a space will avoid the issue in general. For this case, I personally would have done $1$, $2$, $2$, $9$, $2$, $46$, ... since I consider the commas to be part of the sentence, not part of the math (as suggested by Knuth in the TeXbook). This will have the advantage of allowing line breaks to occur within the list, whereas if it is all one expression, MathJax will typeset it as an unbreakable box. $\endgroup$
    – Davide Cervone
    Apr 13, 2012 at 12:35
  • 1
    $\begingroup$ @Davide: That works in this case, but what happens when I want to write an 80-digit number? Arbitrarily inserting spaces where there weren't any in the input seems like something that shouldn't happen quite generally, independent of the possibility of workarounds for particular cases. $\endgroup$
    – joriki
    Apr 13, 2012 at 12:51
  • $\begingroup$ I agree that inserting the characters is a problem. I was only mentioning here that I think the list of numbers should really be a list of separate math expressions, not a math expression consisting of a list. Really a different issue. $\endgroup$
    – Davide Cervone
    Apr 13, 2012 at 13:19
  • $\begingroup$ For an 80-digit number you can add \! where it occurs, or you can add a space after a thousand break. $10.203.040.506.070.809.010.203.040.506.070.809.010.203.040.506.070.809.010.$ $\!203.040.506.070.809.010.203.040$, coded $10.203.040.506.070.809.010.203.040.506.070.809.010.203.040.506.070.809.010.$ $\!203.040.506.070.809.010.203.040$. Line breaks are an issue there :). $\endgroup$
    – MickG
    Sep 24, 2014 at 18:30
3
$\begingroup$

Apparently in the last 24 hours a new version of the code that connects MathJax with Markdown has been rolled out (see this answer). Let's see if that helps this issue at all:

$1,2,2,9,2,46,2,250,37,254,2,31052,2,1480,896,306174,2,2097506,2,6025516,6638,59930,2$

Edit: Yes, it seems to work! So it appears that this may be a moot point, at least for new answers/questions.

$\endgroup$
5
  • $\begingroup$ Let's try in a comment: $1,2,2,9,2,46,2,250,37,254,2,31052,2,1480,896,306174,2,2097506,2,6025516,6638,59930,2$ Edit: Drat! But it does seem that it is specific to comments. So that suggests that the place where the characters are being added is in the comment-handling code. That makes sense, since comments only have limited formatting, and don't go through the full Markdown process. Perhaps there need to be modifications made to help protect math within comments from being modified. $\endgroup$
    – Davide Cervone
    Apr 13, 2012 at 13:24
  • $\begingroup$ There's another strange, probably related phenomenon in my browser with the above comment. The line that starts with "Edit:" isn't wrapped; it extends beyond the right margin and is truncated in the middle of the second 'n' in "handling", where the light grid background starts. The next line starts with "limited formatting". Here's a screen shot. When I first commented on this, the subsequent refresh of the comments caused the line to be wrapped, but when I deleted the comment the problem reappeared. $\endgroup$
    – joriki
    Apr 13, 2012 at 13:36
  • $\begingroup$ Interesting. What browser and OS are you using? It probably has something to do with the in-line equation being wrapped for you (it is not long enough for that to happen for me). $\endgroup$
    – Davide Cervone
    Apr 13, 2012 at 13:39
  • $\begingroup$ Yes, it's wrapped; the final $2$ is on a line by itself. Firefox 11.0, Mac OS 10.6.8. $\endgroup$
    – joriki
    Apr 13, 2012 at 13:48
  • $\begingroup$ OK, I did some checking and it appears to be a bug in Firefox (version 11 at least -- I didn't look at earlier ones). I will have to look into it further. $\endgroup$
    – Davide Cervone
    Apr 13, 2012 at 14:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .