Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
Hi Andrew,
I was writing something that quotes some source from the nLab expecting it to render properly on the nForum. I thought the itex was more compatible than it seems. For example, “\vec”, “\dot” and “\ddot” work on the nLab, but not the nForum.
You probably explained why somewhere before. Can you refresh my memory?
Thanks!
For example, “\vec”, “\dot” and “\ddot” work on the nLab, but not the nForum.
They do for me: typing
$\vec v$, $\dot v$, $\ddot v$
produces
, , .
You maybe have the wrong text filter selected. See below the comment box. You need “Markdown+Itex”-
They are working for me now too. Hmm. I do certainly have and had Markdown+Itex selected. Perhaps Andrew worked some magic sense I posted?
Now “F\in\Gamma” is not working. The culprit seems to be “\in”. I see. It seems like there needs to be a space after “\in” (after some trial and error).
Edit: By putting a space after “\in”, I can get to work, but “F\in \Gamma(T X)” doesn’t seem to work no matter what I try besides splitting into two pieces (see Source).
Ah, I see. Good to know.
I would never have run into this problem, because I always include whitespace everwhere.
If I weren’t wary of the ensuing discussion (which I don’t have the energy to get into), I would ask you all to also generally add more whitespace in LaTeX code for mathematics on the Lab. Every now and then I go and fix somebody’s diagram or something on the Lab, only to find a single huge string of symbols in the code, that wraps around the display line several times without any space or line breaks.
I can’t read such code without much effort. And I suspect nobody can. We are humans, not computer parsers. Let’s write human readable code!
I agree Urs, that we have to read human code, but I often have an opposite problem – when something is very sparse and takes a large space I have hard time visually capturing it, scrolling through it, and organizing myself in. Some people write big letters and big spaces and many pages, some like dense letters with only a couple of pages per lecture. The bias toward sparse and elaborate or, on the other hand, toward laconic code and writing is not universal, “human” is not universal.
On the opposite spectrum of my own biases, in programming, LISP is very efficient and dense, but I could hardly read it quickly even when I was good at lisp. Most of lisp enthusiasts however consider LISP more readable than C++…
If I were to get involved in the discussion that Urs has not initiated, I would express my agreement with Zoran. (-:O There’s a balance to be struck, and individual preferences may differ. Although I do think we should insert linebreaks tastefully in large displayed formulas.
Back on the original comment, the reason why inserting spaces here and there gets round problems on the nForum is because the nForum caches the maths snippets. If, for some reason, some maths doesn’t render properly the first time around then the blank gets stored in the cache and, unfortunately, gets served every time in the future. The link between the formula and the cache store is based on the md5sum of the formula so adding a space somewhere creates a new md5 and therefore a new request to the server.
Every now and again - basically when someone complains - I clear out obviously mangled stuff from the cache (anything of zero size). I expect that if I did that now then the original formula that Eric complains about would then render correctly (I’m pretty certain since I tried the formula on the itex server and it worked just fine). iTeX on the nForum ought to be exactly the same as on the nLab because it is actually generated by exactly the same program.
As for the vecs, dots, and ddots; Eric, were you on your iPhone when you first looked? I read this thread first on Mobile Safari and the formula didn’t render quite right. But that’s because they’re images and they got cropped a bit badly. Indeed, now that I have a device on which I can’t run Firefox - ie a device that doesn’t render MathML - it’s given me the extra push needed to clean up the rendering of maths for broken browsers. I know what to do .. just need some time to get it in place!
Hi Andrew #8: No, I was not on my iphone at the time. Windows 7, Firefox 10.0.2.
It seems like “anything of zero size” could in theory be detected automatically and not cached at all in the first place. Right? Of course that would be extra work for whoever implemented the caching routine.
That is weird. I meant to post that last expression to demonstrate a blank post and ask you to “See the Source”, but lo and behold! It renders properly when posted.
The issue is with “Preview” it seems. It did not preview, but posted properly.
It did not preview, but posted properly.
I think that this has been reported before. Is a cache used for previews where a fresh rendering is used for posting?
(Eric: Now that you’ve posted it, if you start a new post, does it preview correctly?)
Right now, if I preview anything with math in it, then nothing renders in the preview. (But I’ve only had the patience to wait a few seconds.) I think that this is a known bug indicating a slow server somewhere.
(As a test) I tried and the first bit of maths took a few seconds to preview, but additional bits then were very fast.
Mike (10): Good suggestion. If I ever catch the no-good lowlife who programmed the caching routine, I’ll make him implement that. Actually, what worries me with a simple test like that is that if the nLab server is down then it is better to cache nothing than to try to keep reloading it from the server. So I’ll have a think about that. In the meantime, I’ve made it easier to take out the empties and have just done that.
Toby (14): I’ve been mucking around with iTeX today so you might just have caught it at a bad time.
1 to 16 of 16