This chapter is a collection of notes about the current evolution of Therion, and open problems.
In the distribution there is a file with the “todo” list of the features to add to therion:
Other items are on a wish-list (“would be nice to have”):
station
and mark
wherever equate
is allowed
There are similar lists for xtherion
, and there are annotaions for the internals of the program (not in english). The file TODO.M refers to The Therion Book, and is not in english. Finally the file TODO.M (also not in english) …
When the cave is small, it would be nice to have both plan and extended elevation on the same pdf page. Here is the author's reply:
I am just not sure, how this should be done. I see only one way:
> This I can imagine, but I am not sure, whether this is what you asked for.
In any case - we will open cross-sections sooner or later. I am currently > working on new 3D generation algorithm and for this, we will definitely need > exact positions of cross sections in 3D. So discussion and suggestions are > welcome.
area
Wookey (2005-08-17) pointed out some problems with areas. Infact (M. Budaj) the use of areas should be reduced to a minimum, and replaced, whenever possible, with point symbols.
(subtype value)
If is advisable to avoid areas splitted on two scraps. In that case one should put one area on each scrap, with a straight invisible border line (option “-subtype invisible”) [thwiki 17] where the scrap ends, but there would still be coloring problems (for instance coloring the map with “altitude”). This notwithstanding, in caves with several pools and mud banks, areas splitted on two scrap are almost inevitable.
Another problem happens when you split a line which is part of the border of an area. The two new lines get new ids, while the area still contains the id of the old line (which does not exists any more). Therefore when the project is compiled with therion
, there is an error like (here “l14-480–196” is the old id)
object does not exist -- l14-480--196
A little help comes from xtherion
: clicking on the error, it brings up the map editor with the problem causing area selected. You must go to the “Area control” to check the lines on the border of the area, and find that id. Unfortunately xtherion
does not highlight the area in the canvas and it is not so easy to find the other lines of the border, and to fix the problem.
Another possibility is to search the id with the text editor open on the file listed on the error line.
The problem is that a graphical item, the id of which is referred by another item, is dropped leaving a dangling reference. This is a problem with xtherion
, which should use reference counting techniques to keep into account the number of references to the objects. At a minimum xtherion
should give a warning about deleting a referenced object …
join (.th command)
Probably a similar problem occurs with the “join” command. In this case the work of xtherion
would be more difficult because a “join” connects item from different files, and the “join” appears in a file at a higher (logical) level. xtherion
needs to have this higher-level file open to find whether the deleting item occurs in a “join”.
Another problem is the “Show area” command of the “Area control”. It is useful, but it seems that it shows only the lines of type “border”, and not those of type “wall” or “contour”.
It would be nice if xtherion
interact with a PDF viewer to provide a view of the exported pdf (map or atlas).
This is not very disturbing, because right now one can have two windows, one for xtherion
and the other for the PDF viewer, and switch between them to visualize the output after the therion
processing.
Using xpdf
one could have a tighter integration of the viewer with xtherion
. The viewer could be spawned by xtherion
with the command “xpdf -remote nome_server file.pdf”. In this case, if there is no xpdf
server running, a new instance of the program is executed. On the other hand, if there is one, this is passed a command to open and load (or reload) the requested PDF file.