Not signed in (Sign In)

Not signed in

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

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics comma complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration finite foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

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

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • CommentRowNumber1.
    • CommentAuthorAndrew Stacey
    • CommentTimeMay 27th 2009
    • (edited May 27th 2009)

    I think it's time to sum up our discussions on graphics in Instiki. I'm getting a little lost as to what we're aiming for.

    1. MathML+SVG is not ideally implemented yet so any method that produces mixed diagrams (i.e. graphics and text) is going to be imperfect and the resulting diagrams will need tweaking.

    2. Drawing diagrams in (La)TeX is not a simple affair and the packages that do so are extremely complicated (under the hood/bonnet). Jacques is, understandably, reluctant to implement a hack in itex but is similarly reluctant to implement the whole machinery.

    3. On the other hand, he is willing (may already have done so) to implement a system that allows for alternatives: a picture for the screen and another for the LaTeX output. Indeed, this is already in place if the LaTeX picture is a PDF.

    4. So we need converters. Inkscape will export TikZ so one can convert from SVG to TikZ. I don't know how "nice" the resulting TikZ is, though.

    5. On the other hand, the best bet for TikZ to SVG is TeX4ht and this results in fairly horrendous SVG.

    6. When putting diagrams into Instiki, due to the poor interaction of MathML and SVG then one oughtn't to stack thinks too deeply. It's reasonable to have MathML embedded in SVG or vice versa, but to have MathML embedded in SVG embedded in MathML is asking for trouble. Since the worst seems to be MathML in SVG (for visual reasons rather than technical), it's best to have only simple mathematics embedded in a diagram (probably a good guideline anyway).

    7. Big diagrams can be put on separate pages and included in, but there is potential for reuse within the page so small diagrams should stay inline. Well-formed SVG is more compact than MathML so although the raw syntax looks a little out of place, it's not so bad.

    • CommentRowNumber2.
    • CommentAuthorTobyBartels
    • CommentTimeMay 27th 2009
    This comment is invalid XHTML+MathML+SVG; displaying source. <div> I have a comment on just one of these points; otherwise I agree.<p><blockquote>Big diagrams can be put on separate pages and included in, but there is potential for reuse within the page so small diagrams should stay inline. Well-formed SVG is more compact than MathML so although the raw syntax looks a little out of place, it's not so bad.</blockquote>If the reuse is the reuse of the entire diagram, then having it on a separate page and included in actually makes reuse easier. I guess that you mean reuse with variations, where we want it to be easy for people to get at the code. That makes sense, but I'm not sure that I've actually seen well-formed SVG that features compact code; certainly the SVG in the Lab now is huge compared to anything written there in iTeX.</p> </div>
    • CommentRowNumber3.
    • CommentAuthorUrs
    • CommentTimeMay 27th 2009
    I didn't follow all of this. Could you remind me what

    " Indeed, this is already in place if the LaTeX picture is a PDF."

    refers to? That sounds like something I might be able to immediately connect to.
    • CommentRowNumber4.
    • CommentAuthorAndrew Stacey
    • CommentTimeMay 28th 2009

    Toby, with the unerring discerning eye of a referee you have found the one part where I was a bit vague because I didn't really understand what I was saying! The "reuse" I referred to is not manual reuse of code but some sort of reuse by SVG that means that the server doesn't have to send so much data to the client. I don't really understand it - I haven't looked at the syntax of SVG to know what it's about. Also, having diagrams inline saves a little server overhead. I've no idea how much or whether it's worth it, but given the current state of the server then saving it whatever we can may not be a bad thing!

    Urs, if you put an SVG into Instiki then when you export the page as LaTeX then the picture disappears. That's because LaTeX can't handle SVG so \begin{svg} ... \end{svg} ends up getting gobbled up by the export handler. To get round this, there's the command \includegraphics{file} which does get exported. On the web then \includegraphics{file} does nothing. So when you put an SVG on Instiki then you ought also to upload a corresponding PDF and make sure that you write something like:

    \begin{svg}
    ...
    \end{svg}
    \includegraphics{picture}
    

    to ensure that both the screen and print look right.

    Some of us are arguing that this ought to be replaced by a single system so that one could just write

    \begin{tikzpicture}
    ...
    \end{tikzpicture}
    

    and Instiki would generate the SVG for the web and the TikZ code would survive onto the paper. Others of us are thinking more along the lines of a double system like the current but where instead of \includegraphics{file} one has

    \begin{svg}
    ...
    \end{svg}
    \begin{tikzpicture}
    ...
    \end{tikzpicture}
    

    I'm in the latter group as although the former would be ideal, I don't think that it is yet realisable.

    This shifts the issue to generation of the code so that you don't have to make the same diagram twice. I'm working on this and will hopefully have a prototype for testing soon.

    • CommentRowNumber5.
    • CommentAuthorAndrew Stacey
    • CommentTimeMay 28th 2009

    Found it (I think):

    5.6 The 'use' element

    Any 'svg', 'symbol', 'g', graphics element or other 'use' is potentially a template object that can be re-used (i.e., "instanced") in the SVG document via a 'use' element. The 'use' element references another element and indicates that the graphical contents of that element is included/drawn at that given point in the document.

    • CommentRowNumber6.
    • CommentAuthorTobyBartels
    • CommentTimeMay 28th 2009
    I'm as unclear as you as to what that means, Andrew, but my guess is that inline vs included will make no difference. In particular, the HTML file served by the server to the browser is the same either way, and surely this is all happening at that level.
    • CommentRowNumber7.
    • CommentAuthorAndrew Stacey
    • CommentTimeMay 29th 2009

    I'm getting a clearer picture of how it works. When you define, say, an arrowhead, then you want to reuse it lots. All the pictures on a page can use the same definitions, but I don't think that inclusions can do so. I think it's a bit like local variables in functions.

    • CommentRowNumber8.
    • CommentAuthorTobyBartels
    • CommentTimeMay 30th 2009
    This comment is invalid XHTML+MathML+SVG; displaying source. <div> Can you put something on the SVG Sandbox to test this?<p>Even knowing nothing about SVG, I very much doubt that inclusions will have any more difficulty reusing definitions than inline diagrams. The inclusions are handled by the server; what the browser receives is the same either way.<p>(I could easily believe that definitions can't be reused in a separate SVG diagram, but that would be a problem both ways.)</p></p> </div>
    • CommentRowNumber9.
    • CommentAuthorAndrew Stacey
    • CommentTimeMay 30th 2009

    Can you put something on the SVG Sandbox to test this?

    Done. And it seems to work as you thought it would. Hmmm.

    Also threw up something about what's allowed in SVG in Instiki. My original diagram had MathML embedded in foreignObject tags, but was within div's to get the alignment right. Those divs caused problems with Instiki's parser.

    Anyway, that's my excuse for why the diagrams look so rubbish!

    • CommentRowNumber10.
    • CommentAuthorTobyBartels
    • CommentTimeMay 31st 2009
    And you can even reuse definitions within a separate <svg> element; that's great!

    And I feel justified in my use of slash names for included SVGs, since it really makes a difference which page they're included on. (Not to suggest that inline code is a bad idea —as long as it's human-readably short!)

    • CommentRowNumber11.
    • CommentAuthorAndrew Stacey
    • CommentTimeJun 1st 2009

    Looking a little ahead, we can have a standard SVG style page with a (small) number of predefined objects which can be included in any page that has SVGs on it. I'm thinking at the moment of arrowheads, but other things may be desirable.

    Of course, we don't want to send out loads of stuff just for the sake of it, so maybe not one page but a few (a bit like \usepackage{..}) but it would make for a unified look across the 'lab.

    • CommentRowNumber12.
    • CommentAuthorTobyBartels
    • CommentTimeJun 1st 2009
    That's a good idea, Andrew. I'm not sure what to put on it yet (especially since I haven't actually written any of these SVG diagrams myself, yet), but hopefully that will become clear with time.