Will Robertson wrote: > Hi Jonathan, > > I'm only focussing my comments on two slides: the comparison between > LaTeX and Python documentation, and the slide on the LaTeX3 project. Good choice. Thank you. Here's an executive summary. You can add a slide, and I've made these changes: == \begin{itemize} \item Started in 1993 or so (predates XML, Google, \ldots) \item No-one is using \LaTeX3 for typesetting -\item Last year, \LaTeX3 source placed on SVN server, but \ldots +\item In 2005, \LaTeX3 source placed on SVN server, but \ldots \item They say it's \textbf{explicitly forbidden} to publish \LaTeX3 code -\item Uses proprietary license (Debian accepted, not OSI-approved) +\item Uses unusual license (Debian accepted, not OSI-approved) \item Current activity focused new macro programming interface \end{itemize} === > I think it's fair to say that tug.org is the place to look for LaTeX > documentation: > <http://www.tug.org/interest.html#doc> > I'm thinking that latex-project would do better simply linking there; in > terms of maintenance, it's much better to have a single point of reference. > > So rather than spending half the slides explaining what latex-project > does inadequately, I think you would do better to explain what/how > docs.python does and how this would be beneficial for the LaTeX > community. And possibly whether there are tools that the LaTeX community > could use for this task. I took the point of view of a newbie looking for documentation or help on a particular topic, and visited the pages http://www.latex-project.org/guides http://docs.python.org/ and recorded what I saw. I think I did a reasonable job (although I did have 'web2.0' expectations). Perhaps we could ask some real newbies to take a look (usability study). > The problem, of course, is that Python must have several orders of > magnitude more active developers than LaTeX, and man-power for such > thankless tasks is extraordinarily thin on the ground for us. I think the main problem is that the LaTeX programming and documentation system is print/PDF centric, and does not generate good XML that can be reused and consolidated. > Now onto the LaTeX3 slide. Where should I start? :) > >> ¢º Started in 1993 or so (predates XML, Google, . . . ) >> ¢º No-one is using LATEX3 for typesetting > > LaTeX3 isn't a system to be used for typesetting. At least, not yet. A > less contentious way to word this bullet point might be something like > > "LaTeX3 is a project to continue LaTeX2e past its current status of > maintained but not developed." > > (We've discussed backwards compatibility many times before.) > > "Current work of the LaTeX3 project is focussing on the transition > package authors face in moving from LaTeX2e to the ideas of LaTeX3." > > (I think that gets the gist across instead of implying that LaTeX3 > exists but no-one is using it.) I think I say that when I write >> Current activity focused new macro programming interface The goal of the LaTeX3 project is to produce an improved system for typesetting. No-one, at present, is using LaTeX3 for typesetting. Therefore, this goal has not been met. The simplest way to say this is: >> ¢º No-one is using LATEX3 for typesetting >> ¢º Last year, LATEX3 source placed on SVN server, but . . . > > Actually, it was 2005: <http://www.latex-project.org/site-news.html> Thank you for the correction. I changed the slides. >> ¢º They say it¡¯s explicitly forbidden to publish LATEX3 code > > I think you mean "re-distribute the source of the" rather than > "publish". You make it sound like we're not allowing people to use the > code (which is available on CTAN and through TeX Live/MiKTeX). On page http://www.latex-project.org/code.html it says it is explicitly forbidden to place this material on CD-ROM distributions or public servers. >> ¢º Uses proprietary license (Debian accepted, not OSI-approved) > > What do you mean by "proprietary" here? The GPL is a proprietary license > of the FSF. The Apache Licence is a proprietary license of the Apache > Foundation. Neither of those licences are distributed under the terms of > themselves. I've changed that to 'unusual' > The LPPL solves a real problem in the community: what do we do when > authors retire and their packages become no longer maintained but > another author wishes to step in? Do you think that Karl, Robin, Jim, > Rainer would simply allow me to update someone else's package on CTAN? This is /not/ how open-source works. If I wish to create a new hyperref.sty why shouldn't I. As you point out, if I did this then CTAN would surely put it in a place where TeX distributions would not pick it up. My view is that there is a real problem, and the license is not the way to solve it. That's not how open-source works. Nuclear weapons are a real problem. Some people write software and say: My license forbids it to be used for making nuclear weapons. Fine, but such software is not open-source. >> ¢º Current activity focused new macro programming interface >> >> Here¡¯s an example of the old and new interface: >> >> \def\mymacro #1{\setbox #1\hbox\bgroup} % Old >> \cs_new_nopar:Npn \hbox_set_inline_begin:N #1 { % New >> \tex_setbox:D #1 \tex_hbox:D \c_group_begin_token } > > > expl3 isn't just about renaming TeX primitives for the sake of it: > - toolbox of often-used and otherwise useful functions with consistent > (and readable!) names > - abstract many expansion control problems with better datatypes [examples snipped] If you write a single slide on this, I'll put it in my talk. (And Robin can ask Kate Jeary to make sure I give it reasonable time.) If you don't, and /if/ I have time, I'll have a go myself from what you've supplied. It seems to me that the main thing in what I've snipped is a factory for defining macros. > This is the thing about expl3: we're not really raising the bar on what > *can* be written in TeX macros. Rather, we're making it much easier to > do so; if you can code a simple algorithm simply, it really doesn't > matter if you're using TeX or Lua or Python. In the past, however, it > hasn't been as possible to code a simple algorithm simply in TeX macros. I used to think in that sort of way, but I don't now. Rather, I think that TeX macros are not suitable for this sort of purpose and a different language should be used. A mainstream language. >> It doesn¡¯t even get named parameters (instead of #1). > > There's a lot more that qualifies for "doesn't even get" than named > parameters. I think it's safe to say that not one macro package has ever > failed to be completed because the author had to write ####1 instead of > #foobar. No, but it is a tremendous convenience, and about 6 months ago I posted a solution to this to comp.text.tex. > As we've previously discussed, I believe that interfaces for keyvals are > much more important than whether internal function parameters are named > or numbered (since from the *user's* point of view, it doesn't make a > shred of difference). Yes, and that's another topic - which I cover in my slide Python documents: latex2html and Sphinx -- Jonathan The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).