Re: How do all the metapost parts fit together.
Michael Lake writes:
I see that thPoint.mp contains...
...
and that thdraw is defined in mpost/therion.mp which I think is generated from thmpost.h which is generated from your RCS system. I am trying to work out how this all fits together.
Actually, thmpost.h file is generated from all metapost sources by the script genmpost.pl in the mpost directory. The reason for this is that we had problems to set-up TeX and MetaPost searching paths for macro files indenpendent on used OS and TeX distribution. Now all macros are stored in the therion executable in a form of a string and are written to working directory just before running metapost and tex.
I gather then that you have some scripts that will generate HTML from the file and that the HTML can document the available symbols. Am I guessing right? Like the ASF symbol for a fixed station.
This HTML-like markup is an artefact from 1999/2000 version. There is a perl script which generated HTML documentation, see http://therion.speleo.sk/symlib/ for an example. We plan to make such documentation easier, without HTML markup -- this will require to use standard names for all the symbols, based on symbol names in the Therion Book, e.g. p_sand_UIS for UIS point symbol for sand.
What would be nice would be to generate automatically a PDF doc that has the name of the UIS symbol and it's picture i.e. run a script that processes the mp fragments, extracts the name and desription, creates the eps files and then runs pdflatex to make a table of all the UIS symbols listed alphabetically or by type of symbol.
This'll be no problem then. We want to support also automatical creation of a map legend which would contain only symbols used in particuler map &c.
The reason why I am trying t fit it together is so I can do things like make my own symbols -- well even help you make the many other UIS symbols that arent in therion yet too. I dont know much metapost but can learn. It appears at present that to add new symbols one must add the mp code and then recompile.
It's possible to add/change metapost symbols without new therion compilation. The interface is rather experimental but should work. You may include symbol re-definition in the layout command (after the undocumented `code metapost' command) in the last development version of therion: layout my ... # indicates that following lines are metapost code code metapost # follows an example of an redefinition of a stalactite to empty symbol # # Stalactite is (at present; will be changed soon) internal therion's # name for stalactite point symbol -- look at the first column in # the file thTrans.mp (which maps internal names to names used # in the metapost definitions) # # Parameters count and type is fixed; see the original definition # of the stalactite symbol (p_stalactite_UIS) in the file thPoint.th def Stalactite(expr a,b,c,d) = enddef; endlayout
Also I see you need help with writing some sections in the manual - like the section "New map symbols".
Yes, help is welcome ;) but we have probably to clean 4-years old metapost code first... Then I'll try to write at least some hints how to create new symbols. Regards, Martin
+++ Martin Budaj [03-09-08 12:06 +0200]:
Michael Lake writes:
Actually, thmpost.h file is generated from all metapost sources by the script genmpost.pl in the mpost directory. The reason for this is that we had problems to set-up TeX and MetaPost searching paths for macro files indenpendent on used OS and TeX distribution. Now all macros are stored in the therion executable in a form of a string and are written to working directory just before running metapost and tex.
The main disadvantage of this is that people can't change of add metapost definitions without recompiling therion, right? If the definitions were read at run-time then we could package UIS or ASF or BCRA or whatever symbols separately and install the version you need rather than having a huge executable. I understand why you've done what you've done, but all of us agree it's a horrible hack and I think we should keep it under review if it's really sensible. How big are the definitions so far and how big do we expect them to get? If they are, and weill remain, quite small and only a tiny number of people will want to change them then the current scheme should work OK.
This'll be no problem then. We want to support also automatical creation of a map legend which would contain only symbols used in particuler map &c.
That's a _really_ good idea - I like that.
The reason why I am trying t fit it together is so I can do things like make my own symbols -- well even help you make the many other UIS symbols that arent in therion yet too. I dont know much metapost but can learn. It appears at present that to add new symbols one must add the mp code and then recompile.
It's possible to add/change metapost symbols without new therion compilation. The interface is rather experimental but should work.
ah, I should have read this first.
You may include symbol re-definition in the layout command (after the undocumented `code metapost' command) in the last development version of therion:
layout my ...
# indicates that following lines are metapost code
code metapost
# follows an example of an redefinition of a stalactite to empty symbol # # Stalactite is (at present; will be changed soon) internal therion's # name for stalactite point symbol -- look at the first column in # the file thTrans.mp (which maps internal names to names used # in the metapost definitions) # # Parameters count and type is fixed; see the original definition # of the stalactite symbol (p_stalactite_UIS) in the file thPoint.th
def Stalactite(expr a,b,c,d) = enddef;
endlayout
OK - that should do for now. Welcome aboard Michael, BTW - the more hands the merrier I think. Therion is the way forward but it still needs plenty of work to make it accessible to the less geeky cave surveyor. Wookey -- 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/
Wookey wrote:
The main disadvantage of this is that people can't change of add metapost definitions without recompiling therion, right? If the definitions were read at run-time then we could package UIS or ASF or BCRA or whatever symbols separately and install the version you need rather than having a huge executable.
I understand why you've done what you've done, but all of us agree it's a horrible hack and I think we should keep it under review if it's really sensible. How big are the definitions so far and how big do we expect them to get?
The Official UIS list of cave symbols is available from: http://www.karto.ethz.ch/neumann-cgi/cave_symbol.pl
If they are, and weill remain, quite small and only a tiny number of people will want to change them then the current scheme should work OK.
Its a big list but it is quite static. However it does allow countries to maintain the use of some of their own symbols - for instance in Australia we will be retaining a few of the older symbols. Thus cavers will want to have small customised sets. We reallly therefore need to load them at runtime via a library or a package like LaTeX does. Probably as plain text mpost macros in a file that is called up by the thconfig file. Mike pondered.....
The reason why I am trying t fit it together is so I can do things like make my own symbols -- well even help you make the many other UIS symbols that arent in therion yet too. I dont know much metapost but can learn. It appears at present that to add new symbols one must add the mp code and then recompile.
It's possible to add/change metapost symbols without new therion compilation. The interface is rather experimental but should work.
ah, I should have read this first.
but it was undocumented. :-) I will try and help with documentation.
Welcome aboard Michael, BTW - the more hands the merrier I think. Therion is the way forward but it still needs plenty of work to make it accessible to the less geeky cave surveyor.
I can help with documentation. I am good at LaTeX, I am making some headway with plain TeX (even have Knuths book) and I might have to learn C++ :-) Mike -- Mike Lake Caver, Linux enthusiast and interested in anything technical.
Michael Lake wrote:
The Official UIS list of cave symbols is available from: http://www.karto.ethz.ch/neumann-cgi/cave_symbol.pl
By the way helictites are helictites but your xtherion has them as helectites. From the UIS Page: Translations of Helictites - Soda Straws - Crystals Croatian: Heliktiti - Spageti - Kristali Dutch: excentrieken - macaronies - kristallen French: Excentriques/Helictites - Spaghettis - Cristaux German: Excentriques - Spaghetti - Kristalle Italian: Concrezione eccentrica - Spaghetti - Cristalli Romanian: Excentrite-Helictite - macaroane - cristale Slovene: Heliktiti - spageti (cevcice) - kristali How were you planning to cope with things like the text in different languages. survex uses a lookup table of numbers for error messages and their strings that are output for each language. Perhaps therion could use the uis english text in the program but use a lookup table to convert them to other strings for xtherions menus for french and german etc. What do you use in Slovenia. Mike -- Mike Lake Caver, Linux enthusiast and interested in anything technical.
It's possible to add/change metapost symbols without new therion compilation. The interface is rather experimental but should work.
ah, I should have read this first.
but it was undocumented. :-) I will try and help with documentation.
There is also documented command-line option --use-extern-libs ;-) When used, therion lets TeX and MP to search for macro files in the run-time. Martin
On Mon, 08 Sep 2003 22:11:24 +1000, Michael Lake <mikel@speleonics.com.au> wrote:
By the way helictites are helictites but your xtherion has them as helectites.
This of course a bug (not the first one of this kind :)). If somebody would like to check our point, line and area types and write comments about it like: What has a wrong spelling? What is not understandable? What names should be preferred? (for example: we use popcorn (US) not cauliflower-calcite (UIS))? What symbols are missing? etc.
What do you use in Slovenia.
helektity :)
How were you planning to cope with things like the text in different languages. survex uses a lookup table of numbers for error messages and their strings that are output for each language. Perhaps therion could use the uis english text in the program but use a lookup table to convert them to other strings for xtherions menus for french and german etc.
OK, some words about our view of internationalization: Therion input files language will be only english (like survex). In fact, it's a code and I have a very negative experience with code written in other languages (Micro$oft once released VisualBasic in SLOVAK (something really nasty) - in the next release, they came back to english) 2. We're also not keen on putting other languages into xtherion. The reason is simple, I've a very bad experience with all programs translated into SLOVAK. The translations are usually less understandable - a lot of technical terms have their equivalents in Slovak - but in Slovakia usually english terms not Slovak are used (ok, may be in France or Germany it's different :) . And also, there are allways problems with regional special characters... The last thing is - that terms like stalactites, helictites etc. are a part of input files - so people should understand them anyway. Like they understand words like length, bearing, clino in survex. 3. Therion map and atlas output will be translated into other languages probably very soon. When it will generate lists of map symbols, they will be described in local language. Regards, S.
On Mon, 08 Sep 2003 21:58:47 +1000, Michael Lake <mikel@speleonics.com.au> wrote:
Its a big list but it is quite static. However it does allow countries to maintain the use of some of their own symbols - for instance in Australia we will be retaining a few of the older symbols. Thus cavers will want to have small customised sets. We reallly therefore need to load them at runtime via a library or a package like LaTeX does. Probably as plain text mpost macros in a file that is called up by the thconfig file.
Even with the current version of therion, if we would have metapost code for ASF (Australian Speleological Federation) symbols, a command like export map -layout symbols-ASF should work. All we need to do is to clean the mess, we have in the therion - metapost cooperation (a lot of old macros, some bugs, names of macros etc.). I believe a week or two should be enought for this. S.
This is mail from Wookey, he sent it to the old conference. So I'm resending it to the new one - therion@speleo.sk. The old one is disabled. S. +++ Stacho Mudrak [03-09-08 16:04 +0200]:
On Mon, 08 Sep 2003 22:11:24 +1000, Michael Lake <mikel@speleonics.com.au> wrote: If somebody would like to check our point, line and area types and write comments about it like:
What has a wrong spelling? What is not understandable? What names should be preferred? (for example: we use popcorn (US) not cauliflower-calcite (UIS))? What symbols are missing? etc.
I'll try and look these over whilst packaging the next version. Although I'll be very happy if Mike beats me to it :-)
OK, some words about our view of internationalization:
Therion input files language will be only english (like survex). In fact, it's a code and I have a very negative experience with code written in other languages (Micro$oft once released VisualBasic in SLOVAK (something really nasty) - in the next release, they came back to english)
Agreed.
2. We're also not keen on putting other languages into xtherion. The reason is simple, I've a very bad experience with all programs translated into SLOVAK.
The translations are usually less understandable - a lot of technical terms have their equivalents in Slovak - but in Slovakia usually english terms not Slovak are used (ok, may be in France or Germany it's different :) . And also, there are allways problems with regional special characters...
The last thing is - that terms like stalactites, helictites etc. are a part of input files - so people should understand them anyway. Like they understand words like length, bearing, clino in survex.
I understand what you are saying - I agree that anything in xtherion which is really referring to the element names in the therion input file should match up. On the other hand it is definately necessary to have proper local language translations for menus, error messages, help and documentation to allow software to be widely used by those who don't already speak good english. Eventually the xtherion interface should get to the point where many users will only use it via the graphical interface and won't be editing text files much at all. When that is true it is important that the meaning of symbols is easily understood, and the cross-reference to the code in the data files becomes less significant. So, I do think that translations are necessary in the user interface, but I agree that the need for the correspondence with the data-files to be clear, makes this problem harder than usual. Displaying both a translation and the string that will be netered in the data-file is probably best, but it might have to be switchable because they won't both fit on the screen. We probably have more important things to worry about at this stage, but I don't think it's right to say 'xtherion is only in english' as a policy. Survex's portuguese support, for example, has made it very popular in Brazil. This wouldn't have happened if it had been english-only. And survex has the same aspect as therion in that the data files are essentially in english. Translating the user-interface is definately a good thing and we should put the infrastructure in place, otherwise whilst the output can be read by anyone, only those who read good english can use the software.
3. Therion map and atlas output will be translated into other languages probably very soon. When it will generate lists of map symbols, they will be described in local language.
OK Wookey -- 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/
+++ Stacho Mudrak [03-09-09 14:20 +0200]:
This is mail from Wookey, he sent it to the old conference. So I'm resending it to the new one - therion@speleo.sk. The old one is disabled.
Ah yes - that's mutt's fault - I tried to set a new 'therion' alias and mutt just told me that I already have an alias of that name and won't let me define a new one. Unhelpful bit of software! I've binned the old one manually now. Wookey -- 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/
+++ Wookey [03-09-09 14:20 +0100]:
+++ Stacho Mudrak [03-09-09 14:20 +0200]:
This is mail from Wookey, he sent it to the old conference. So I'm resending it to the new one - therion@speleo.sk. The old one is disabled.
Ah yes - that's mutt's fault - I tried to set a new 'therion' alias and mutt just told me that I already have an alias of that name and won't let me define a new one. Unhelpful bit of software! I've binned the old one manually now.
And now I';ve found the 'right' answer - there is of course an 'unalias' command. Mutt is amazingly clever but sometimes it's not at all obvious how to do what you want. I'll shut up now :-) Wookey -- 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/
Wookey wrote:
So, I do think that translations are necessary in the user interface, but I agree that the need for the correspondence with the data-files to be clear, makes this problem harder than usual. Displaying both a translation and the string that will be netered in the data-file is probably best, but it might have to be switchable because they won't both fit on the screen.
We probably have more important things to worry about at this stage, but I don't think it's right to say 'xtherion is only in english' as a policy.
Of course, you're right. When I'll do internationalization for output strings (we need it for maps in Slovak), there will be no problem to use same routines for error messages (because it's the same stuff). And also there is nothing easier, than to add some script to xtherion make process, that will also enable xtherion to use source file with messages written in multiple languages. I believe, it's a question of one evening.
Survex's portuguese support, for example, has made it very popular in Brazil. This wouldn't have happened if it had been english-only. And survex has the same aspect as therion in that the data files are essentially in english. Translating the user-interface is definately a good thing and we should put the infrastructure in place, otherwise whilst the output can be read by anyone, only those who read good english can use the software.
I think, that it's more psychological... Once we've written a program completely in Slovak and people here in Slovakia liked it very much. Than when we stopped developement of it and told them, that WinCompass is really better and easier software for them to use - they didn't use it. Even if they've understood the basics of english. May be the manual in Slovak was missing, but may be, they really need translations of menu items... OK. When therion will support multiple languages of output, it'll support also multiple languages at least in error-messages and xtherion menus... For other items in xtherion (that need to be named according to input files - like point types), I'll try to add support of translations into status line (there is short help in english currently). This could be a reasonable compromise. S.
participants (4)
-
Martin Budaj -
Michael Lake -
Stacho Mudrak -
Wookey