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.
Would it be easy to add \llbracket and \rrbracket to the tex commands understood by the nLab parser?
I will take a look. Should be possible.
Hi Mike, I had a quick look, and I can easily parse it and replace it by some unicode character(s), which is what itex2MML does in such cases. But it’s not immediately obvious to me which unicode character(s) to use. I imagine two square brackets next to one another is not going to look great (edit: I’ve used two square brackets in the Sandbox currently, maybe it looks OK after all).
Hmm, maybe I found it after all. Is this what you are looking for?
Implemented now with this symbol. Seems to look pretty good to me, see the Sandbox currently. Fortunately itex2MML interprets anything beginning with \ as an operator even if it doesn’t recognise the operator, so what I have done is post-process the MathML rather than process the LaTeX: the MathML has the correct code for an operator (e.g. so it scales correctly), and then the post-processing replaces llbracket and rrbracket by their corresponding unicode symbols. [Edit: I’ve tweaked Initiality Project - Overview to use the LaTeX code now].
Note by the way that this will only work on the nLab, not the nForum unfortunately. I’m not really touching the nForum much at the moment. But maybe just hacking it with two square brackets, or using the unicode symbols directly, will suffice on the nForum.
Yes, that’s the symbol I was looking for. Awesome, thanks!
If this sort of thing is easy to do, what about implementing \esh for ʃ?
Now that I’ve done it once, it’s trivial. Were it not for the fact that the source has not yet been committed to github, I would encourage you to do it yourself :-). Have implemented \esh now (again, only on the nLab, not the nForum).
Thanks!
The vertical operator scaling on \llbracket and \rrbracket is behaving oddly in places; they seems to scale based on the entire math formula rather than on what’s inside the brackets? See for instance point (3) at Initiality Project - Totality. Can they be made to scale only based on what’s inside the brackets? If not, then I think it would be better if we could make them not scale at all by default and require marks like LaTeX’s \left and \right if we want them to scale.
Do other people see the behavior reported in #9 too?
Yes I’m seeing the behavior you describe: image
Yeah, that’s it, although for me it’s even more pronounced. Is this the expected behavior of a MathML “code for an operator” (as mentioned in #5)? An operator is of course not the same as a delimiter, semantically – does MathML have a notion of “delimiter”?
I see the same (Firefox on a Mac).
My apologies for not looking into it yet. Will do so when I get the chance. I guess it’s readable at the moment, even if not optimal; if it’s not readable in places, let me know, and I’ll try to prioritise it.
No worries, and no hurry; it’s plenty readable.
It seems that in MathML, a delimiter is to be coded as an operator, but it looks like it should be within an <mrow> to make it scale correctly, see under ’form’ here. I can try to fix that when I get the chance. But maybe it is something that you’d like to take a glance at, Mike? I will upload the source in a second. (Edit: now done, the repository can be found here).
1 to 16 of 16