Queries and comments on 0.2.17
wookey at aleph1.co.uk
Fri Feb 13 18:55:31 CET 2004
+++ Stacho Mudrak [04-02-11 09:47 +0100]:
>> I'm sorry, currently I'm short of time, but I'll try to write down at least
>> some comments.
>>> >How do I control overlap at joins? I have drawn a couple of scraps and at
>>> >the place where they join there are contour lines on one scrap and
>>> >ceilinglines on another that sort of intermingle. When drawn up therion put
>>> >one scrap on top of the other and invents a 'join line' that covers quite a
>>> >lot of the neighboring scrap. I need transparency, or a complex 'join
>>> >What is the best way to deal with this? Do scraps have
>>> >to have perfect joins? Can I draw a join line?
>> I'm sorry, but this I do not understand :((( Could you please draw me
>> exactly what you have in your mind?
I have put a picture of a screen shot of the scrap join and the resulting
PDF image online to illustrate how one scrap cuts off parts of the other at
the join - how should this be done to produce a satisfactory effect?
>> Joining two scraps together covers only joining the walls - not the lines
>> inside. They can be joined only by detail specification, you mentioned
OK - I hadn't appreciated that - this is important if there are features in
the passage at the joins. Is it a requirment that there must be no passage
features at the join that could be misaligned? If a whole cave has rocks or
sand on the floor this could be a problem.
>>> >Also I tried to control the join in more detail by specifying that the ends
>>> >of lines join but the syntax didn't work. What's wrong with this:
>>> >join farsidewest:0 at farside2.river farsidewest2:end at farside.river
>>> >(farsidewest are farsidewest2 are 'wall' lines).
>> Nothing - it should work. If it does not - it's certainly a bug. Does
>> therion generates an error or it simply does not join the lines?
>> Did you
>> tried this without :point specification (just farsidewest at farside2.river
>> farsidewest2 at farside.river)? This should work also.
Therion generates an error. 'invalid object name', but some more research on
the various options shows that I get:
join farside at river farside2 at river
works OK (except that it joins one (the south) wall of farside2 to a nearby
column (the nearest wall) which is just wrong.
join farsidewest1 at farside.river farsidewest2.farside2 at river
Gives 'survey farside.river does not exist' - which is right but I mean
scrap farside within survey river - have I got the syntax wrong?
join [fsceil1:0]@farside.river [farsidewest3:8]@farside2.river
'invalid object name' - but mnaybe this is the same problem as the line above
The best reuslt is obtained with no 'join' at all but then the walls don't
quite join up (which is odd because the scraps are drawn on a survex plot
and thus acurately scaled - the walls should join up almost exactly anyway...)
>>> >In the test editor, using above: data normal left right up down newline
>>> >tape compass clino and
>>> >then 'scan format' to get data table to have correct boxes is OK but when
>>> >you enter data it appears as
>>> >tape compass clino
>>> >station left right up down
>>> >which is the wrong order.
>> This is not a bug.
OK. I'll think about that a bit more - it not important.
>>> >When a created file is re-read every blank line gets a 'text' entry in the
>>> >file commands section, and when saved ends up as 3 blank lines - whitespace
>>> >text entries shouldn't appear.
>> I thought, I've removed all such bugs. But do not have this experience. Do
>> you have a "text" item before each point, line? If yes, this has probably
>> something to do EOLN characters. Do you have the same experience on each
>> operating system?
I only tried it on Linux. I just tried again loading the fale and saving,
but making no changes with 0.2.18 and the problem did not recurr. Maybe I
have to make changes - maybe it is fixed - I'll send you an example if I can
reproduce it. The file has LF only throughout.
>>> >If I try to zoom in to 200% therion just crashes (64MB machine, 3.8Mb pnm
>>> >Is this expected?
>> 200% of 3.8Mb = 4Mb original image + 16Mb scaled image + 20Mb canvas RGBA
>> buffer = 40MB = 60% of RAM. This may be a problem, especially on some
>> operating systems.
OK. So there is a need for original scans to be quite small, or lower colour
depth (I have to scan greyscale because my scanner/software does not work
properly in b/w). Now I'll reduce the colour depth of all the images and
maybe chop them up for therion editing, because zoom is important and it's
_very_ slow to load. I also just bought 128MB more ram, which should help.
Presumably the software could be made to manage larger images better (like
photo-editing software can load file _much_ bigger than the available
memory). a 4MB scan shouldn't be 'too large to zoom' - it will catch users out.
Perhaps the zoom should only attemtp to zoom the visible part of the image,
not the whole thing. That would be sensible use of resources. Is this a TCL
feature that it will be hard to change?
>> Tcl/Tk supports only these file types. But:
>> Install Img plug-in into your Tcl installation.
OK - I'll try and find it. It's not obviously part of Debian, but it may
well be there somewhere.
>>> >Shortcuts for moving things between scraps would be helpful, otherwise it's
>>> >'move down' about 100 times. Is there a better way?
>> Right. No way right now. I'll think about it (adding a button move to
And a key! there are nothing like enough keyboard shortcuts. Mice are nasty
and give you RSI :-)
>>> >It's very tedious if you need to change a number of entries - need
>>> >to move between boxes in RH-side or to scroll up and down items in the file
>>> >summary. e.g if you need to change all the station ids to names. Need to be
>>> >able to navigate file commands with keys.
>> We have in our minds building much more intuitive user interface, but...
>> Anyway, you can use text editor and regular expressions find and replace...
Except for the fact that you have to unload the map editor first otherwise
it will overwrite them, and then you can't remember which objects to edit...
And because it takes 2-3mins to load again I don't like unloading and
loading it each time to make an edit. Smaller scans will help, as will more
memory, but there does need to be a better way if drawing a survey is to
take less than 100 years :-)
>>> >graphical stuff
>> Last thing: thanks a lot for your feedback. We'll think about it a lot...
thanx for taking it all seriously. I think we are getting to something that
is useful, but various things are still too difficult or too slow.
I'll send you the article text so far by the way, so you can check I didn't
say anything wrong.
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
More information about the Therion