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 am looking for a convenient way to have just few (mainly public) pages from Lab used at a server at which I have no possibility to run special scripts and so on, just have more or less static pages. Here is a tiny example
http://www.irb.hr/korisnici/zskoda/validity+of+interpretation
Andrew kindly gave us a script for making a local copy of the entire Lab, which works only partially (I mean the redoing the links to make them local and so on works, but the files are not interpreted as xhtml by firefox unless the extension is changed afterwards and if it si not changed it displays without proper javascript, hence formulas are not right). Here I am saving manually just selected pages, both xhtml of the print version and nLab/instiki source. With xhtml I need css etc. files which I want just in one copy, so I edit the xhtml-source head to replace the directory of such with a canonical copy so that I do not duplicate it (the files are much bigger than the xhtml of the page, that is why). For source saving, I of course do not want html, and I do not want to open the edit button and scroll copy to be safe from not locking it and mistakenly copy but rather go to source button and than select all and copy it to emacs editor, what is a bit cumbersome. But a more improtant question is that I am not sure about special characters in the sourcecode. For example
(∞,n)
copies in the original form, but I am not sure that all our special characters used in Lab source are in fact OK with default settings of emacs.
So, I am going my way through but couple of advices may be helpful.
The main reason for all this is that I find the environment good for developing few pages not of Lab related content so I do not want to host them in Lab (even in private pages part!). So what I can do is to edit such a page within the scratch page of the public section of my private lab, save it at another server in the form as above explained, and then change it to a version with null content. So I use the compiling correctly, but do not save anything permanently in Lab (even not in my private part) as every editing session ends with zero code in scratch. So, even the history button can not reveal what were the past version (there would be one final version per session (consisting of edits with less stops than half an hour), final version always zero code).
Edit: I made few changes to the above text!
Hi Zoran,
To know how best to help or advise you, I need to be sure that I understand the goal of this. Is it to produce webpages that contain mathematics? So you’re using the nLab essentially as a converter to XHTML+MathML+SVG. Is that right? Is there anything particular that depends on it being the nLab here? (To make that precise, if I had another Instiki installation somewhere that was set up functionally exactly as the nLab (same CSS and colours) then could you use that instead of the nLab?).
If so, would you consider a slightly different workflow? Are you able to install stuff on your own machine where you do the editing (so not on the webserver where you want to put this stuff)? If the sole use of the nLab is to convert to XHTML then it may be easier to install the conversion part on your own machine and set up emacs to call the converter (so instead of calling pdflatex to convert to PDF, it calls maruku to convert to XHTML).
If that’s not possible, that’s not a problem, but before going further I’d like to know that to narrow down the possibilities.
Incidentally, Emacs can handle unicode just fine, but sometimes you need to be sure to tell it that you are using unicode files.
Hi Andrew,
one of my questions is already answered I think: you say that the only special characters in the source are unicode characters and that cut and paste keeps all of them intact even if they are not possibly correctly displayed. Thus it it works for an infinity symbols than I do not need to check the whole file for all special characters that they went OK from the manually copied sourcecode to the emacs. In my test with the infinity sign I did not tell emacs that I am using unicode and it correctly preserved the code for infinity (and even displayed it well). So I am not quite understanding if I need to worry about “telling unicode mode” or not.
Unfortunately, I am not much of a goal-oriented person, but rather synthetically oriented, so let me answer the best I know.
In principle, I would not mind doing the conversion at my local unix machine (the one I could theoretically run scripts on, not the web server) for most purposes and take it from there, though I see no advantages of this approach (regarding that the algorithm I described gives no trace other than a new null-content version of a private n-lab page and that it has a disadvantage that I do not have always access to my local unix host). Regardless of my question I should try local maruku soon (hopefully soon after the Split conference on homological mirror symmetry and categories 11-15. july is over).
(I am not sure if I am instantly able to install though. I use ubuntu, and some installations of the software work fine and for some I just get message that some of the missing dependencies “won’t be installed” and they indeed can’t for some reason (for example, I can not install skype on this machine so I am using a bad alternative!). I should reinstall the whole OS etc. later this summer, but with fragile things going on now, I should not delve into this now and risk some parts of my present system not to work fully in future version. After that probably everything will work nice. But when I am at work I am usually not having access to that machine, and would not like the installation at XP.)
It is not solely the I want to have converter to math-enabled html as I do have e.g. a personal wordpress page and can do it there, their way. The thing is that I like the interoperability with the Lab at various levels: transfer of parts of the sourcecode being the most important aspect. I consider my interest space unified and want Lab to be part of it, but not the other way around, to inhabit Lab, even the private part, with much stuff not belonging there. For example, the philosophy page of the Lab is about philosophy related to math and physics and especially to categories. Above mentioned book on validity of interpretation of texts would be probably unsuitable inserted in a list of references there (just for the sake of argument accept that opinion). So why my own page on my server would not take the Lab page with my own additions? (this is not a primary type of example, but one of those which occurs often to me in creation process). Another example is to adjust pages different way for each different group of students, regarding peculiarities in the level and background. The third example is of course to have in the same format non-math pages. Now I may later want to transfer back to Lab some of my code. So the uniform source format is a plus (while not a must for most purposes).
But you see, regardless how I do similar things in a massive task, it is good that i learn how to do well ad hoc grabbing and else-installing of the temporary (versions of) pages the cheap way I described above (with only one copy of background .js and .css used files).
Please do not think hard about this. Only if you have quick ideas/suggestions or see that I am doing obvious blunders into non-necessarily inapt ways. To large extent, I am OK with the crude way I just tried and described above.
The thing is that I like the interoperability with the nLab at various levels
Yes, I was taking that as a given. You want to be able to use the same source and produce something that could go in an nLab page, or something that could be a standalone webpage. So the key is the input format.
Let me repeat my question, with an additional:
[[some page]], the <nowiki> tags, the category: X (I think), and probably a few other things that I forget.No, it is not important. I can use whatever equivalent for the development and source of the transfer to a regular server (in which I am not a root), though I see no advantage if such existed (unless I keep the stuff there permanently, what is clearly not my intention).
I could do without things like category and nowiki tags. On the other hand, partly yes, it may be somewhat useful to have interlinks like those implied by double brackets in the source code. I could use however site-dependent prefixation to relativize absolute links. So unless I am embedding large chunks of existing Lab code what is not my immediate intention, I may do without double bracket and alike things as well and do absolute links possibly with some flexibility of symbolic URL prefixation.
I hope that this mode I am describing may be useful for others as well.
Right, so the conversion is mainly controlled by the ruby script maruku, with itexToMML providing the mathematics (but note that that is called from within maruku). So the core of what you are doing could be done by running maruku on the source file. If you can install it locally, that would be best, otherwise it might be possible to set up a “conversion only” system that took an input file, ran maruku on it, and presented the result for downloading. No caching, and no saving, just pure conversion.
As you say, the CSS and javascript stuff only has to be installed once. The issue after that is ensuring that the converted pages refer to it correctly, but I think that that sort of thing can be handled by maruku.
The Instiki conversion is neither a subset nor a superset of maruku’s conversion. Instiki adds the wiki-syntax, but it also turns off a couple of things within maruku, such as the page meta-data: it is possible, for example, to specify the page’s title from within the source file.
Good. So I will use the ad hoc manual tricks for the handful of pages I may need before the conference and make the effort to make a good local install of maruku on a first opportunity after the mid july conference. Thanks.
Sounds like a good initial plan.
It will probably take a bit of tweaking to get the output right, and I’m sure that others will be interested in the process, so make sure you keep us up to date with what you’re doing.
Right.
1 to 9 of 9