December 2006 - Therion

Re: [Therion] therion notes
by Ladislav Blazek 18 Mar '08

18 Mar '08

http://search.cpan.org/dist/HTML-WikiConverter-DokuWiki/ HTML::WikiConverter::DokuWiki adds the DokuWiki dialect to HTML::WikiConverter allowing the conversion of HTML to DokuWiki markup. Usage: html2wiki --dialect DokuWiki input.html > output.wiki L. marco napsal(a): >> really nice documentation. What about migrate this to therion wiki > pages? > > i would like to have a wiki output filter, > but i never had enough motivations to put my head to it. > do you c++ ? > > marco > > -- Ladislav Blazek

8 15

Tex memory exceeded
by Wookey 20 Mar '07

20 Mar '07

I just added 20 cross sections and now my map fails to process with: converting scraps ... done making map ... done This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) entering extended mode (./data.tex (./th_enc.tex) (./th_texts.tex) (./th_resources.tex) (./th_fontdef.tex{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}) (./th_formdef.tex Runaway text? ! TeX capacity exceeded, sorry [main memory size=1000000]. l.47627 \PL{ 249.81 181.74 250.44 181.80 250.46 182.14 c}% If you really absolutely need more capacity, you can ask a wizard to enlarge me. Here is how much of TeX's memory you used: 292 strings out of 97341 2961 string characters out of 1211748 1000001 words of memory out of 1000000 Do I really need to change this (how?) or is it probably something else that has gone wrong? That 'runaway text?' looks suggestive. What I really need to know is how to debug it. I ran therion -d so now I have a /tmp/thTMPDIR full of mysterious stuff. Attached is data.tex from there, which seems likely to be relevant. Is that enough to determine what broke? The current full dataset is in svn at wookware.org, which MartinS now has access to. And whilst I'm here: I would also note that adding scraps in a 900-line file is almost unbearably slow on a 900Mhz machine. It feels like something in the code does a linear search so it gets slower and slower to add each line/item. ctrl-r produces about a 15-second wait. I supppose I should just have put all the x-sects in another file. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

3 10

Docs and debian packaging
by Wookey 05 Jan '07

05 Jan '07

I have made the 0.4.1~pre20061221 debian packaging of the latest snapshot. This includes the wiki docs and the current source and debs are available at: http://wookware.org/files/therion/ However I have a problem with the packaging. Debian packages normally include the original source tarball plus a debian diff for the changes. However the changes now include all the wiki html and images. The images are not representable in a diff so it doesn't work. The above package has been done without an upstream tarball for the source. I am not sure what to do about this. I see these options: 1) uuencode all the images Pro: farily simple - packagin needs to uudecode them all before normal packaging - no other changes. Cons: Makes source 35% bigger - not totally crazy but still 1Mb extra. Makes packaging more fiddly due to need to convert to/from uuencode whenever there is a wiki export update 2) Make therion a debian native package Pro: can then just use standard mechanisms No wasted space or extra faff Con: therion isn't a debian native package, and it means I can't do a debian update without there being abump in the therion version. This has caused problems with survex so I'm not too keen. This is effectively what has been done with the debs I've currently built. 3) Include wiki export in upstream tarball Pro: Makes things trivial from my POV Con: You may not want to do this as you already have the wiki - do you want docs in source as well? Makes source much bigger: dump is ~3.5MB 4) Split therion source docs and code upstream Pro: has the same effect as 3, but code download is still small. Con: You need to do a bit of work to move thbook sources into docs tarball So, the question for therion authors/admins (who shouldn't really have to worry about debian packaging), is do you think including the wiki docs in either the main source tarball or a different docs one (and move the thbook into that too) is a good idea or not? If you do then I suggest this is the best way to go. If not I will probably go the uuencode route for now, unless/until someone has a better idea. Sorry to bother you with this - I had never realised that debian diffs cannot introduce binary files not in upstream - it's a bit cack really in a situation like this. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

4 7

Re: [Therion] texlive support in therion
by Wookey 04 Jan '07

04 Jan '07

On 2006-12-19 12:20 +0100, Norbert Preining wrote: > Hi! > > On Die, 19 Dez 2006, Norbert Preining wrote: > > > Although for the purposes of texlive compatibility I think the > > > existing 0.3.10 in debian testing will be just as good. > > > > Ok, can take a look at this, too. > > Hmm, it is quite hard to check for dependencies in the source c++ code. > I have another idea: Can you send me some typical file which should be > compiled with metapost and pdflatex (or whatever)? There is a set of files for a large project here: http://wookware.org/mulu/mulu.tgz common_layout.th has some metapost code in it. The .th2 files are the ones that describe the lines and symbols use to draw each section. the thconfig file sets which files and styles are used for each dir (try benarat/terikan/ as a reasonably complex and complete example). As I said I'm not sure this is really going to help that much as it is too far removed from Tex to be relevant. I think the tex, mpost and (maybe) texenc dirs in the source are the bit that show what tex and metapost functions are used. > I have seen comments on metafun, too, do you use context? I don't understand this question. Martin, Stacho? > As I said, the best option is to send me some medium complicated files > which should be do-able with the dependencies, and I will check them. > Thank Well that Mulu.tbz tarball is an example. Unpack it. and apt-get install therion. Then cd benarat/terikan therion and watch it process. (You can do therion at the top level but that could take a while). I suppose I could try the same thing with texlive and see what happens. But right now I need to produce some output for an expedition leaving just after xmas. I'll try Texlive once that panic is over. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

3 6

3d file wall models - scrap connections
by Wookey 30 Dec '06

30 Dec '06

I very much like the 3d map output into survex .3d format. However it does seem to have a problem at joins. It all looks lovely in plan view, but as soon as you look sideways you will see that there is often a vertical offset in the lines at the join. I can see that there _might_ be a pitch at the pont of the join, but normally a smooth transition in the vertical as well as horizontal plane is desired. How are the vertical co-ordoinates at the ends of scraps determined, and is it possible to msake sure they 'join' (have the same co-ordinates) both vertically as well as horizontally? The option to say 'add vertical lines to complete join' would be useful for cases where there is a step height change (e.g the connection between menagerie_s4 and terikan.reifticious_s1). But I'm not quite sure how/where this might be done. If it is hard, then joining everything up would be much better than it is now. See http://wookware.org/mulu/MuluWalls.3d, then look at it on a bit of a tilt. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

10 32

Interface Comments/Suggestions
by Wookey 28 Dec '06

28 Dec '06

OK, after a major drawing session, here are a few general comments on therion/xtherion. I'll send a seaprate mail with things specific to my project: 1) I get very bored of typing '-subtype invisible' after clicking on border. Somekind of shortcut for selecting commonly-used subtypes would be really useful. A dropdown showing available subtypes according to selcted line would be a simple way to do it (and would help when you are not quite sure which ones are available). But having border (invisible) in the main menu next to border would really help. The problem is that people's favourite lines probably vary with person and cave, so being able to configure this might be best. (ctrl-B or ctrl-I to select it would be good for me). This implies a general mechanism for configuring key shortcuts or favoured line-types, which may not be easy. But anything would be better than typing '-subtype invisible' hundreds of times. 2) cross-section drawing. Overall this is still very tedious - there are various things that could be done to make it better. scale: The new update scale button is a big help, but I still find I have to do things like look up the length of a nearby plan line in the .svx file in order to find the LRUD info or otherwise get a scale so I can then set the scale by using the stations (and rotating top right point so line is at approx 45 degrees). This seems such a waste of time when the passage width is right there next to the section, and clearly the scale should match. I can't easily tell if the passage is 2, 5, or 20m wide, but therion already knows. Perhaps the scale for X on an xsect could default to the same as the dist between the walls under the section line (and Y is same as X), and N is up the page? Then the drawer can change that if it is not right. scrap names: I got very bored of creating a scrap then having to select it and change the name to <scrapname>_c1 or whatever. Can x-sects be set to have such a scrapname by default, incrementing the number? Part of the problem is that there is no link between the x-sect scrap and the section line on the plan/elevation. Only the point has a link. It seems to me that xsections are logical entities and making sure all of the line, the scrap and the point are associated is a good thing, which will help with the grouping of sections into boxes when that is implemented. Associated with this is the need to give each section a 'display name' or label like 'E3' or whatever. Have I just missed this facility? 3) xtherion should warn you when you accidentally create lines outside of a scrap. It is easy to do and slow/fiddly to put right. Is there ever a valid reason for creating lines outside a scrap? I can't think of one. Automatically removing null lines might be useful (a line entry that just has one point and does nothing but confuse - are these ever useful)? 4) The xtherion interface needs more work on shortcuts generally as we use it so intensively. More keyboard options for chanigng between common line and point types and moving to next scrap in the scroll list. e.g only showing lines in the current scrap and showing lines from other scraps collapsed or greyed might do the trick? 5) I don't believe the 'right click to select line hidden below' is working. When I have a line at a scrap join on both scraps (because there is an area join here), I can only selectone line. I have to move it out of the way to get the other one. 6) I need a much faster computer and/or more RAM. :-) Large files take forever to load or change scale. pdf rendering takes minutes too, and I can't open a browser and aven and xtherion and a PDF file all at once. xtherion can get left a long way behind (but at least it does do all thing you asked eventually). This part is not your fault, although the tcl of xtherion doesn't help - that is a really big job to fix, although finding someone to re-write it in gtk would be very good 7) General issue of mixing cave- and map- and project-specific layout options. There are layout options that you want to set globally for the project (e.g. symbol types), options you want to set for the cave (name, rotate, author), and options you want to set just for this plot (map-header position, exclude pages). It is currently difficult to set this up so that it works well. The newish 'copy' and 'input' commands ought to provide the right flexibility but I keep finding I am inheriting some inappropriate settings. I'm not sure about this - it probably isn't therion's fault, but I get the feeling it could be made a lot easier for users to separate the various types of layout option. I'll have to think about this. OK, that'll do for now. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

3 3

Wiki FAQ page broken
by Wookey 28 Dec '06

28 Dec '06

I just edited the last entry on the wiki: "How to access lines or points on top of each other?" in order to tidy up the formatting (it was cut directly from an email). (using the edit button for just that item, not the whole page) But whilst that now looks better - every other entry seems to have lost all the line/para breaks so it looks a mess. I'm not sure what is going on here. I could mess with it a whole load more, but that might just make things worse. Could our wiki-expert take a look? My browser tells me there is one html whinge: HTML warning: line 134, input camp outside <form> but that was there before it went horrid-looking too so is irrelevant to this problem. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

3 3

cross-section drawing
by Wookey 26 Dec '06

26 Dec '06

Thanx to Marco for his really useful therion by example (although none of the pictures appear for me in the dillo browser - is this a feature of the way the wiki works, or are they currently missing?) I have started drawing cross-sections. It's incredibly tedious. I hope I am missing some tricks to speed things up. Drawing the x-sect line, point and outline is OK. But the part about the scrap-scale is a real faff. My x-sects are drawn on the plan alongside the cave, and their natural scale is 'the same as the plan'. It would be nice if there was some way to specify the scale as 'like scrap foo'. On non-graph paper it is very hard to determine the correct 'real size'. Nothing in the drawing view shows me scale to guestimate from. I had to go and run aven to get the length of a nearby leg which had stations marked on the drawing, then compare that to the x-sect size. This is why 'same scale as scrap foo' would be so useful. The biggest problem is finding the corner-markers. Took me a little while to realise they were only visible when the scrap line is selected. But then on a large scan they are impossible to find. The only way I could find them was click on a section point and note co-ords, go back to the scrap line and type in the co=ords so that the red marker appears over the section point and can be moved to the top-right/bottom-left corner. Especially when you have a load of xsects to do, all of which have the same scale, some better way is needed than the above. How do others do it? I have added a para to Marco's doc on the wiki about this. BTW I want to put this (marco's) doc into the Debian Therion package as it is really useful. Can we generate HTML from the current wiki version easily? (I think this may have been answered before - must check the archive). Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

4 13

bug in 0.4.1
by Wookey 25 Dec '06

25 Dec '06

If you add a line label with -text "Name<br>2ndline (i.e forgetting to close quote), then save the file you get an error about unclosed quotes and xtherion hangs. (dec 21 build, on Linux) Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

1 0

Area border problems
by Wookey 24 Dec '06

24 Dec '06

The latest version of terikan.pdf and terikanatlas.pdf are at http://wookware.org/mulu/ I have now understood the use of select and maps to get the layers and previews I want (cool!) Some queries: 1) Why can I click on the internal hyperlinks in the preview map windows and the level labels ('high level passages' etc), but not the page-numbers indicated to N,S,E,W ? They all work on one of the example atlas maps. Do I need to add a rune to enable this? 2) Area problems: See the river (blue :-) ) on the upper half of the survey, 'riverlelvel passages'. (easier on the single-sheet survey). Between the labels 'Arrow inlet' and 'River passage' there is a 25m diameter rock pillar on north side which has got coloured in blue. I tried reversing the line but it's still deemed to be part of the water area. Why? A bit further east the area has inlcuded a couple more rock pillars and a mudbank that should be between them. This bring up the whole issue of pillars inside areas. What is the correct way to indicate these? (There are quite a few rocks in the river with a similar problem. Further easy still (just before 'sump three') the area has gone all strange where it should be bounded by a mudbank border and some rocks. I'm not sure what is going on here. This whole area is a complex one with a lot of edge segments. 3) Currently if a passage is coloured then all the closed loops within it (blocks/rocks/boulders) come out with a double-tint as the colour is presumably applied twice. I don't think I really want this - rocks should be the same colour as the passages they are in. How do we fix this? 4) river colour. How do the metapost colours work. 3 RGb values? rising or falling? I want to make the river/water a much lighter blue but I tried fiddling with the numbers and above (0, 0, 0.95) was as good as I could get. Perhaps what I really need is some cyan, or maybe a transparency/saturation setting. Suggestions? That'll do for today :-) mulu.tgz contains a tarball of the cdata with e all the pics and maps and other huge files taken out. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

2 1