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.
Hello,
Is it a better idea to add images instead of writing latex code and rendering it here? Diagrams do not seem to be as good as in say some wordpress site.
There are some restrictions on what codes one can render (I guess tikzcd is not possible to render). So, I think it is better to add images so that it looks better.
Good idea in my view! Just upload the pictures to the nLab, so they do not disappear. I have ideas of including tikz in my reworking of the rendering, but no idea when I will find the time.
I would actually say no: please use the nLab math formatting facilities whenever possible. The big problem with uploading pictures is that it is much more difficult for other people editing a page to modify them. The fact that anyone can edit any part of a page is fundamental to the meaning of a wiki like the nLab; it’s regrettable that our diagrams don’t look quite as nice, but I don’t think a slightly improved appearance justifies breaking the basic nature of a wiki. (When it comes to diagrams that literally can’t be reproduced in our wiki-syntax, then I think it’s more acceptable, but I generally just try to avoid such diagrams.)
Diagrams should definitely go on the Technical TODO List (nlabmeta)!
please use the nLab math formatting facilities whenever possible. The big problem with uploading pictures is that it is much more difficult for other people editing a page to modify them.
I agree, that is at least for images that have been generated rather that captured by a screen grab.
The nLab could use some sort of subsystem for generated images that keeps around their source code and can regenerate them as PNGs or SVG. Wikipedia sort of has a convention of providing source for images but doesn’t address regeneration. See https://en.wikipedia.org/wiki/File:5_lemma.svg, https://en.wikipedia.org/wiki/File:2-commutative-diagram.pdf.svg, and https://en.wikipedia.org/wiki/File:Categorical_pullback_(expanded).svg.
Instiki does include an SVG editor. However, in practice it doesn’t seem to be very practical. Maybe the ideal would be a syntax that one could type into the source of a page that would result in the server rendering a standalone latex document to get an image that it would save and then automatically include when displaying the page.
Of course, another disadvantage with images of any sort is that they don’t scale the way text does when a page is zoomed.
Of course, another disadvantage with images of any sort is that they don’t scale the way text does when a page is zoomed.
A .svg file is an image file that can be anywhere that say a .png file can, and they do scale. The Wikipedia examples I listed above indicate that there is a way to go from tex to svg.
One does want SVG files not to contain characters but instead svg encodings of them to avoid the layout problems caused by different people having different default fonts.
How about posting the diagram as well as code hidden just near the diagram?
% something when you render in some latex compiler will hide that something.
So, you can write the code in that % so that it is not visible unless you try to edit and any one who want to edit the diagram can use the code.
Sorry, of course in #5 I meant to say “bitmap images”. SVG is, as it says on the tin, the Scalable Vector Graphics format. Converting LaTeX/TikZ to SVG seems like a good idea, although judging by the answers here we might have to go through PDF or DVI first.
I don’t think instiki currently has a way to insert “comments” in the source that aren’t rendered at all in the browser, does it? If it did, I suppose including the source alongside the image would be one approach, but it would require every editor to manually compile, image-ify, and re-upload the diagram, which isn’t ideal.
Mike’s points are good ones. Maybe you could use standard nLab code for simple diagrams, Praphulla, and images for the others. You should be able to use HTML, so you could include the source code inside a
.svg){kind=link}
<div style="hidden">
block or similiar. Maybe give it an id that allows us to recognise it as containing diagram source.
Definitely I’d suggest not to use the SVG editor. Actually I would like to remove it from the nLab, just haven’t got around to suggesting it yet.
Definitely I’d suggest not to use the SVG editor. Actually I would like to remove it from the nLab, just haven’t got around to suggesting it yet.
When you do find the time (thanks!) maybe also remove the button right above, saying “Make this page and S5 slide show”. The only effect this button has had in the past is that users accidently generated spurious edits, which we then had to undo.
Thanks @Richard williamson. I will try doing like that next time :)
Praphulla Koushik, which diagrams specifically do you want to typeset?
@Urs : Hello Sir,
Most of the commutative diagrams, for example the diagram in https://ncatlab.org/nlab/show/cokernel
For such simple diagrams, the available array-hacks seem to be sufficient:
To make this come out decently, just be sure to stretch the arrows:
For horizontal arrows use \longrightarrow instead of \to or \rightarrow and similarly \longleftarrow etc.
For vertical arrows use \big\downarrow instead of just \downarrow, etc.
The above is typeset with
\array{
A &\stackrel{f}{\longrightarrow}& B
\\
\big\downarrow &{}^{(po)}& \big\downarrow
\\
1
&\longrightarrow&
coker(f)
}
It’s not perfect, but also not too bad.
@Urs :
It looks definitely better. I will try to imitate this idea where I think a diagram can be made better.
Thanks.
Okay, good. You can further stretch horizontal arrows by labeling them with sufficient whitespace, such as \overset{\phantom{AAAAA}}{\longrightarrow}
For instance adjunctions etc. come out well this way:
generated from
\mathcal{C}
\underoverset
{\underset{\phantom{AA}R\phantom{AA}}{\longrightarrow}}
{\overset{L}{\longleftarrow}}
{\bot}
\mathcal{D}
1 to 16 of 16