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.
I have finally got around to implementing something I’ve been planning for a while: one can now use Tikz diagram syntax verbatim in the nLab to create diagrams. One can see a simple example currently in the Sandbox (Revision 1739).
I plan to add some more substantial examples soon to some knot theory related pages. But basically just use \begin{tikzpicture} \end{tikzpicture} exactly as you usually would. The only difference is that \usetikzlibrary{...} commands have to be placed inside this block, not outside of it.
What happens under the hood is that the renderer compiles the picture using pdflatex (with the standalone document class), then converts it to an SVG using pdf2svg, and then includes the SVG inline in the HTML source. To avoid compiling every time, it is thus a good idea to make such diagrams on their own pages, as has been standard practise earlier as well for SVG diagrams.
I will also update the HowTo pages eventually to describe this possibility (and to remove some outdated stuff).
Wow, that’s super awesome! This has the potential to make the diagram rendering on the lab much easier to use and prettier-looking.
Any chance of supporting tikzcd?
Re: avoiding compiling every time, have you considered caching the results indexed by the tikz code, so that an edit elsewhere on the page that doesn’t disturb the diagram wouldn’t trigger a re-render of the svg? Editing a page with diagrams on it (especially many small ones) would be much easier if the tikz code were right there in the page.
Thanks for the feedback!
Any chance of supporting tikzcd?
Yes, that should be straightforward to add. I will try it later.
Re: avoiding compiling every time, have you considered caching the results indexed by the tikz code, so that an edit elsewhere on the page that doesn’t disturb the diagram wouldn’t trigger a re-render of the svg?
Good question! Yes, I have considered it, and it is a good idea. Indeed, one could hope for this ’local edit’ functionality for everything; it would massively speed up the saving of edits. But since at the moment the nLab page source does not internally have much structure, it is not obvious to me how to implement it in general. But I think it is definitely something to aim for the future. For anything in an environment, like tikzpicture, it should be possible to consider the contents of that environment to be local. But we still need the mechanics of recognising whether a change has been made in that environment, etc; perfectly do-able, but some work. We can add it to the wish list.
Editing a page with diagrams on it (especially many small ones) would be much easier if the tikz code were right there in the page.
Absolutely, one can certainly still do this. The compile time is not too bad. I am doing that at longitude of a link component.
I was not too keen on the old syntax for centring, so I have now added the LaTeX syntax: one can surround anything that needs centring with \begin{center} and \end{center}, or one can use the British English spelling. See the two diagrams at longitude of a link component for an example.
As requested in #2, I’ve now added support for tikz-cd. Basically one just does the obvious thing: use a \begin{tikzcd} ... \end{tikzcd} block in the usual way. There is an example at rotation permutation [Edit: link fixed].
The size of the SVG graphic that comes out with no scaling is too small, at least on my screen. Thus if no options are passed in square brackets after \begin{tikzcd}, the renderer will add some so that it scales. If any options are passed, no scaling will be applied, and it will need to be done manually. The options I am using to scale with are the following.
[row sep=huge, column sep=huge, transform shape, nodes = {scale=1.25}]
Of course, with this method of producing commutative diagrams, the text is generated by LaTeX, so the fonts may not match the surrounding ones well. It actually looks fine though on my screen for the example at rotation permutation [Edit: link fixed].
I don’t think it’s important for us, but I’ll just note anyway that pdf2svg, which is what generates the SVG graphic from the pdf outputted by pdflatex, has a quirk that the text is not actually semantically text, it is a path.
What may be more important is that, in particular, the text is not MathML, so we do not have the semantic value of that. On the other hand, very few of the commutative diagrams on the nLab currently have MathML in them, even amongst those which are SVG graphics.
Hi Richard, I think you meant rotation permutation?
Great job on tikzcd however! It always seemed strange to me that nlab didn’t have support for it, but now that it has it will look much prettier. :)
Happy new year.
Richard, this is amazing. Could you maybe add a brief paragraph on the tikz functionality to HowTo? Briefly indicating what and how? Then we could point people to that.
Would it be easy now to similarly add xymatrix-support?
Yes, this is amazing! I’m looking forward to trying it out.
Somebody alerts me that the functionality breaks in the history of a page.
See for instance Sandbox rev 1743, which, right now, should be equal to Sandbox, but is not.
Thanks very much for the feedback!
Re #8: Yes, rotation permutation is the correct page now (I changed the name), thanks!
Re #9: Yes, we need to add to the HowTo. I plan to do that soon. In the last few days, I have been working on another feature I have long been planning (at least half way done now), namely reference handling. Once I am done with that, I will go through the HowTo to try to update it with all the new syntax possibilities.
We should definitely add xymatrix support. It should be fairly straightforward to adapt the code for the Tikz rendering. I’ll do it when I get the chance.
Re #12: The new renderer is only switched on for the current version of a page (this has cropped up before :-)). Thus all historical versions of any pages which use any new syntax (this includes the earlier LaTeX support I have added) will not look entirely right currently, and will also load more slowly in general (if at all for very large pages). This will be fixed eventually, but I do not consider it high priority. If one wishes to do a diff, one can always look at the source.
Re #12: The new renderer is only switched on for the current version of a page (this has cropped up before :-)). Thus all historical versions of any pages which use any new syntax (this includes the earlier LaTeX support I have added) will not look entirely right currently, and will also load more slowly in general (if at all for very large pages). This will be fixed eventually, but I do not consider it high priority.
This makes it impossible to use the Sandbox for testing and asking for advice. For example say I created Sandbox rev 1743 and thought that it was not behaving the way I thought it should. The only way others can see its behavior is looking at the current Sandbox as long as it hasn’t been overwritten yet. Of course one could create something like tkiz issue 1 to try to make it more permanent but that too would have the overwriting problems if it bot fixed and nobody could see the “bad” version.
I definitely agree that it is not optimal :-). As I say, it will be fixed eventually, it is just not a high priority, because I don’t feel it is a very significant problem for the average user (i.e. reader) of the nLab. With very limited resources, we have to take things gradually; the benefits should hopefully outweigh the downsides. I do weigh up these kind of things when making a decision about implementation of something.
Definitely I would suggest not to create new pages for any issues. Just adding a polite message to the Sandbox to ask for something not to be removed should suffice.
Richard, that makes perfect sense, of course.
Have there been a volunteer or two recently offering help with such matters? Or maybe it’s hard to distribute workload on such matters.
This is not a criticism, I’m just curious: why is it a significant amount of work to turn on the new renderer for history versions?
I don’t think its a significant amount of work to turn it on, just that Richard hasn’t gotten round to it yet. The history versions run some different code, so the renderer has to be placed in that area as not to break things. Just a guess.
Yes, exactly, what Ali wrote is correct. Thanks!
Regarding help, I am always open to and welcome it. Jake and Ali have kindly expressed an interest in contributing, but it is more on frontend stuff at the moment, whereas this is the backend that needs tweaking. The codebase is also not easy to get started developing with. Eventually I will aim for us to divorce ourselves from being a fork of Instiki, and reorganise things, and then it should be easier. We are already a long way along that road: many components are now independent APIs.
Thanks for adding tikzcd! This is great.
When we add this to the HowTo, we could also add a link to the tikzcd editor (linked today in an MO question that’s since been closed).
Maybe we should also discuss whether we should have nLab-wide recommendations for the creation of diagrams. Personally, I think for any diagram that doesn’t map naturally onto a grid, or which contains diagonal arrows, or arrows that are longer than one grid square, or three or more parallel arrows, or any 2-cells, tikz(cd) or xymatrix will produce a much more readable result than our current \array approach, and should be the recommended choice, even to the point that existing diagrams should be upgraded whenever possible.
For very simple diagrams like a single commutative square, or perhaps two commutative squares side by side, or a single adjunction with labels on both arrows, tikz(cd) or xymatrix will still look nicer, but the \array versions of such diagrams are fairly readable and I could imagine someone arguing that its advantages might make it preferable (e.g. fonts and semantic information as in #7, or rendering speed). I don’t think I would argue that myself, and I will probably switch to tikzcd even for simple diagrams myself; but if someone else wanted to make that argument, then we could consider a “respect the author” policy that already-existing such diagrams shouldn’t be upgraded.
Thoughts?
Richard, could you post the link to the nlab source again? (Is it recorded on some nlab or nlabmeta page?)
@Mike There is a github repo but Richard doesn’t use it currently. I think the main nlab code is being developed locally? The main functionality is all there though.
I have a little more time in January, so there’s a chance I might be able to have a look at the codebase, if it were available somewhere.
Just to say that I’ll be happy to abandon the \array-hack in favour of tikz.
I suppose the only theoretical advantage of Instiki’s \array functionality over decent diagram typesetting is its potential searchability after turned MathML. But first of all it seems this potential searchability is hardly realized in pratice (?) and, second, since the tikz source code will be available at least alongside our rendered pages, a clever search engine might find whatever there is to be searched for in the diagram after all.
Re #23 and #24: it’s correct that I’ve not pushed my local git repo to github since July, partly for reasons of perfectionism (I was planning to push when the renderer is fully completed), but mostly because there is a hook which automatically propagates changes to github to the server, which is a bit risky with the current nLab development setup. I’ll try to remove the hook and then push what I have as soon as possible. Would be excellent if you do wish to become involved in the codebase, Mike. It is more modular now with the new renderer, e.g. I didn’t write a single line of Ruby on Rails code for the tikz/tikzcd diagram functionality.
Re #25: potentially we could include the MathML as well, by post-processing the rendered SVG source to replace the text with MathML (an SVG is, as you probably know, just a text file in its source). Indeed, we have the tools to do it right now, it is just a question of time for implementing it. It would be low priority I suppose. If anyone is interested in that, it would be an excellent example of a highly modular task, one would only need to work with two or three python files.
If you want to keep the propagation hook on the main repository https://github.com/ncatlab/nlab, you could fork it to your personal github account and push work-in-progress versions to the latter, merging them into the main repo (e.g. with pull requests) when they’re complete. Then other potential contributors could also make their own forks and submit pull requests.
Thanks for the suggestion! With just me working on it for the moment, it’s convenient to push to master, so I’ve removed the hook for now (am not that keen on it anyway; I think hooks are good for testing and things like that, but I’d like to keep deployment manual, at least until such a day as we have comprehensive tests which run after a merge). But if you or anybody else wishes to begin contributing, I can stop pushing directly to master and instead make pull requests (and everybody is very welcome to fork and make pull requests as you suggest).
I’ve now pushed what should be the latest source to the repository. The last commit is enormous, it is a conglomeration of what I have been doing since July, mostly on the new renderer, but a few other things here and there as well. For those who’d like to join in (I really encourage just dipping into some small task, I am happy to test and improve, so there is no pressure to make it perfect or even work correctly), I’d suggest to look at the Python APIs under script/src. The renderer API is under script/src/renderer, but relies on a number of small little libraries in the same directory. The tikz diagrams API is large enough to reside elsewhere (though it is used by the renderer), under script/src/tikz_diagrams. Ignore script/src/citations, this is related to a significant new feature I am currently trying to complete (proper referencing/citations).
All of the Python APIs can be tested in isolation. However, many do rely on MySQL and some environment variables being set. If anybody is serious enough to want to get MySQL set up as well as the environment variables, I will help with that.
Great, thanks for updating it. I’ll see if I have a chance to look at it. We can of course also mix methods: you can push directly to master and the rest of us can submit pull requests.
Great! Absolutely.
Sorry, our posts crossed a bit; the last two paragraphs in #28 were posted after #29.
I should say that nobody need feel that they must write in Python, you can use whatever language you like, just make into something that can be called.
Sorry, our posts crossed a bit; the last two paragraphs in #28 were posted after #29.
That’s the problem with editing a previous post to add new stuff rather than just making a new post… (-:
Indeed! The joys of mutability… :-).
This is not quite the right place to ask the following, but let me do it anyway:
Could you remind me: Is the section at HowTo on How to Download a Local Copy of the n-Lab up-to-date?
Do we know how many people are or have been making such local copies?
If not too many, we should maybe advertize this a little.
Not really up to date, I have introduced a new way to do this, but it’s been a bit sidelined by other things. It’s very important, so we need to look at it as soon as I have a chance.
Is there a way to introduce nlab links to tikz-diadrams, like
\begin{tikzcd}
\text{[[Polish space|Polish]]} & \text{[[regular space|regular]]}
\arrow[Rightarrow, from=1-1, to=1-2]
\end{tikzcd}
?
Not currently, unfortunately. The issue is that the combination of tools that are used to produce the SVG figure from the tikz code lead to text being rendered as paths. Maybe there is some way around this, but I do not know of one for the moment.
Is it possible to place two diagrams next to each other, horizontally?
Apologies, I overlooked #38 at the time. Yes, it is possible, but you’d have to use some CSS, i.e. it is the same question as placing any two HTML elements next to each other horizontally.
Today I noticed a small bug in the tikz diagram renderer, fixed here.
1 to 39 of 39