# Start a new discussion

## Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

## Site Tag Cloud

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

• CommentRowNumber1.
• CommentAuthorMike Shulman
• CommentTimeOct 18th 2018

Would it be easy to add \llbracket and \rrbracket to the tex commands understood by the nLab parser?

1. I will take a look. Should be possible.

• CommentRowNumber3.
• CommentAuthorRichard Williamson
• CommentTimeOct 18th 2018
• (edited Oct 18th 2018)

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).

2. Hmm, maybe I found it after all. Is this what you are looking for?

• CommentRowNumber5.
• CommentAuthorRichard Williamson
• CommentTimeOct 18th 2018
• (edited Oct 18th 2018)

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].

• CommentRowNumber6.
• CommentAuthorRichard Williamson
• CommentTimeOct 18th 2018
• (edited Oct 18th 2018)

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.

• CommentRowNumber7.
• CommentAuthorMike Shulman
• CommentTimeOct 18th 2018

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 &#643;?

• CommentRowNumber8.
• CommentAuthorRichard Williamson
• CommentTimeOct 19th 2018
• (edited Oct 19th 2018)

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).

• CommentRowNumber9.
• CommentAuthorMike Shulman
• CommentTimeOct 28th 2018

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.

• CommentRowNumber10.
• CommentAuthorMike Shulman
• CommentTimeJan 3rd 2019

Do other people see the behavior reported in #9 too?

• CommentRowNumber11.
• CommentAuthormaxsnew
• CommentTimeJan 3rd 2019
• (edited Jan 3rd 2019)

Yes I’m seeing the behavior you describe: image

• CommentRowNumber12.
• CommentAuthorMike Shulman
• CommentTimeJan 3rd 2019

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”?

• CommentRowNumber13.
• CommentAuthorTim_Porter
• CommentTimeJan 3rd 2019

I see the same (Firefox on a Mac).

• CommentRowNumber14.
• CommentAuthorRichard Williamson
• CommentTimeJan 3rd 2019
• (edited Jan 3rd 2019)

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.

• CommentRowNumber15.
• CommentAuthorMike Shulman
• CommentTimeJan 3rd 2019

No worries, and no hurry; it’s plenty readable.

• CommentRowNumber16.
• CommentAuthorRichard Williamson
• CommentTimeJan 7th 2019
• (edited Jan 7th 2019)

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).