There is a great list of packageable answers at the previous thread. So now we need to start thinking about how we move on from here. Some points to consider:

  • Where do we host the code?
  • Where should we host discussion? And bug tracking, etc. ?
  • What coding style do we use?
    • Self-documenting code?
    • Naming of internal macros?
    • LaTeX package or TikZ/PGF library?
    • All in a single file or one file per answer?
  • How should we name the package?
  • Other things?

There is now a chat channel: http://chat.stackexchange.com/rooms/409/from-answers-to-packages

Launchpad page: https://launchpad.net/tex-sx


Status Update (2011/06/24):

Andrew Stacey

Aspects that are completed or near completion:

  • Braids; needs testing
  • Calligraphy; needs testing
  • Matrix cells; needs testing
  • Angled ends to paths; needs converting to dtx, testing, and documentation
  • Labelling equations; needs converting to dtx, testing, and documentation
  • TQFT diagrams; needs testing
  • Soft path library (not intended for use by users); needs testing and documentation

Things that have been started but are a little further away

  • 3D perspective coordinates
  • Paths in hyperbolic space
  • Knot diagrams (no files in the launchpad repository for this)


The following are steps to test the code. There are variants of these (for example, for those who know about bzr repositories), but these are as simple as I can make them.

  1. The code is located at http://bazaar.launchpad.net/~tex-sx/tex-sx/development/files
  2. Select something you want to test. If it has a .dtx file, you have to have that. If there is a relevant _test.tex file, that might be useful (the _test.tex files are my (Andrew Stacey) test files.). If it only as a .tex file, that's both the "style" and the test file (but the ones with .dtxs are the more important for testing).
  3. Run pdflatex on the .dtx. That will produce the .sty file and the documentation .pdf file.
  4. Try to set up a test document. I'm not going to give more instructions here as ideally it should be possible to do this from the supplied documentation.
  5. If there is no documentation, look at the _test.tex file if it exists. If the code hasn't yet been converted to a .dtx then the .tex file is all there is; it will have the code and samples, but no documentation.
  • I'd be willing to do some testing, but maybe you could outline the procedure for acquiring the requisite files?
    – Seamus
    Jun 24 '11 at 9:21

For Code hosting, I am in favor of using bzr, as that is the VCS I am usually using. I have used Subversion in the past, but find it somewhat limiting in terms of branching flexibility (though since this project is rather limited in scope that probably won't matter too much).

Discussing should mainly happen here, in order to be visible for everyone at TeX.SX.

  • I have an own server which runs Subversion and Trac (Bug tracker, wiki, source browser, etc.) which we can use. I never used bzr yet. I think we should be fine off with Subversion with such a small team.
    – Martin Scharrer Mod
    Apr 7 '11 at 18:18

What coding style do we use?

In general I would go with a normal DTX style.

All in a single file or one file per answer?

Definitively multiple files. At the very least during coding. Some of the solutions can be coded as TikZ libraries which should be a single file each.

How should we name the package?

Why not call it tikztexsx.


Other things:




  • ????

Although it's not in the list, I took the liberty of adding my TQFT answer to this package. I've yet to write the documentation, but otherwise it's ready for testing. As a standalone style file, it can be downloaded from http://bazaar.launchpad.net/~tex-sx/tex-sx/development/view/head:/tqft.sty

Here's a sample test file:


\begin{tikzpicture}%[tqft flow=east]
\foreach \coord/\style in {
  {(0,0)}/{tqft view from=outgoing,fill},
  {(5,0)}/{tqft view from=incoming,draw},
  {(0,-10)}/{fill=orange,fill opacity=.5,tqft boundary lower style={draw,blue,ultra thin,dashed},tqft boundary upper style={draw,green},tqft cobordism style={draw,purple},tqft boundary style={fill=yellow}},
  {(5,-10)}/{fill=orange,fill opacity=.5,pair of pants,tqft cobordism style={draw,purple},tqft boundary style={fill=yellow,draw=green}}%
} {
  \edef\styleit{\noexpand\tikzset{every node/.style={\style}}}
\node[pair of pants] (a) at \coord {};
\node[reverse pair of pants,anchor=incoming boundary 1] (b) at (a.outgoing boundary 2) {};
\node[cylinder to prior,anchor=incoming boundary] (c) at (b.outgoing boundary) {};
\node[cylinder to next,anchor=outgoing boundary] (d) at (b.incoming boundary 2) {};
\node[tqft cylinder,anchor=incoming boundary] (e) at (a.outgoing boundary 1) {};
\node[tqft cylinder,anchor=incoming boundary] (f) at (e.outgoing boundary) {};
\node[reverse pair of pants,anchor=incoming boundary 1] (g) at (f.outgoing boundary) {};
\node[tqft cap,anchor=outgoing boundary] (h) at (a.incoming boundary) {};
\node[tqft cup,anchor=incoming boundary] (i) at (g.outgoing boundary) {};

With result:

tqft diagrams

  • @Andrew: Maybe I'm mistaken, but didn't you want to post this at the other thread? May 3 '11 at 16:28
  • @Hendrik: I probably should have done as well, but I figured that it was already in near-package form so actually was appropriate here as well. Here, I'm saying, "This now should be looked at by others" whereas there I'd be saying "Shall we include this?". I'm going to include it whether people like it or not (well, unless there's a huge outcry) so I'm jumping a stage. May 3 '11 at 18:53
  • @Andrew: OK, thanks, so I was mistaken :-) May 3 '11 at 18:56
  • @Hendrik: Not really, I was just lazy - I should put it there (and my braids one and possibly the knot one too). May 3 '11 at 18:57
  • @Andrew: If you don't want the knots in a separate package of its and your own, then it has to go in there! May 3 '11 at 18:58
  • @Hendrik: I feel that the knot stuff is a little less well-defined than the others; same - but to a lesser degree - with the braids. I'm not sure I've gotten it right yet. I need to talk to someone who's a little more used to producing knot diagrams to know what they would like from such a package. May 3 '11 at 19:11
  • @Andrew: Sounds reasonable, but surely your example knots look nice! May 3 '11 at 19:15
  • @Hendrik: I know, but just because I managed to get nice looking diagrams doesn't mean that it is obvious how someone else should do it. I want to have a nice easy interface. The braid example is a bit simpler because there's an obvious way to present a braid, but there's no standard way to present a knot. May 3 '11 at 20:38
  • Or rather, there are standard ways to present a knot but producing a nice picture of one seems to be a bit of an art. May 3 '11 at 20:39
  • @Andrew: Ah, only now I looked at the code that produces each knot - indeed, that doesn't look obvious. But I think it's very much worth pursuing this since the output is great! May 4 '11 at 8:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .