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.
Split page from reflective factorization system, with some additional characterizations.
It looks like markdown and math are turned off inside \begin{center}
. Seems like a bug?
Also I am having issues with tikzcd: the following is rejected, although it works fine on my computer:
\begin{tikzcd}
x \ar[dr] \ar[drr,"{\eta_x}"] \ar[ddr,"f"'] \ar[dr,"{\lambda_f}" description] \\
& \bullet \ar[r,"g"'] \ar[d,"{\rho_f}"] \ar[dr,phantom,"\ulcorner"] & L x \ar[d,"L f"] \\
& y \ar[r,"{\eta_y}"'] & L y
\end{tikzcd}
And one more: when the renderer rejects a page save with an error, it would be useful if text entered in the “describe this edit” box were not lost.
Ah, the problem with my tikzcd diagram is that \ulcorner
wasn’t defined. I didn’t see this in my testing because I generally use amsart
, so I don’t have to manually load the ams packages. Could you add the ams math packages to the compiler for tikz?
Huh, now the two rectangles in the proof look totally bizarre. All the arrows are there, but the letters appear to be redistributed randomly to the vertices and labels, with some of them turned into bullets.
Have added AMS latex packages now. Looking into the other issues.
The centring issue was tricky, due to the fact that Maruku will not render anything that is inside a tag, but I think I’ve found a way around it now. As usual, this kind of thing will not be a problem once Maruku is removed.
The labelling issue I had noticed previously, but was hoping was an isolated problem. Clearly not! It is very bizarre: I can only guess that something (either SVG rendering, tikz, the standalone package, or pdflatex) must not be thread safe. I will look into it.
I cannot quite believe it, but it looks like the labelling issue is something to do with the way SVG is rendered in the browser. E.g. if one looks at the HTML source of the individual diagrams on this page, copies each locally, and renders each individually in the browser, then they look correct I think.
This means that it is going to be tricky to fix! Maybe we cannot inline all the diagrams. Or maybe we have to post-process somehow. I’ll keep looking into it.
Ah, I see, I think. Some ids are generated in the SVG source like ’glyph0-0’, and these are repeated across diagrams. I will be able to fix that.
Hopefully fixed now. I’ve regenerated this page, but not the other one where the issue was seen. Please check that the diagrams look correct now, Mike.
Have now pushed yesterday and today’s bug fixes to github. See here.
I will add preservation of nForum announcer text upon an error when I get the chance.
Ah, #10 makes sense! And it explains why they rendered fine in the Sandbox, since a bug like that would only affect a page with more than one such diagram. Thanks for fixing, they all look great now. I am so excited to finally be able to draw nice-looking commutative diagrams!
Great that you are putting the new functionality to use!
I have now implemented the request from #2 that the announcement text is not lost when an error occurs. I have tested it as far as I can, but let me know if you encounter issues. Pushed to github here.
I think all requests/bug fixes mentioned in this thread have now been addressed.
Awesome, thanks!
Re #15: fixed a bug. Pushed to github here.
As far as I know it’s not even a bug: the center
-environments are a hack that doesn’t properly talk to the Instiki rendering engine.
On the other hand, it does seem to work with the Instiki-hyperlinks, but not with Instiki-math.
In the present case I have removed the center
-environment and instead added some whitespace by
$\;\;\;\;\;\;\;\;\;\;$
That’s also a hack, of course, but at least one that is supported by Instiki. :-)
Finally, I have replaced the broken link [[left exact reflection|left exact]]
by
[left exact](reflective+subcategory#ExactReflectiveSubcategories)
1 to 20 of 20