With the recent discussion and welcome submissions of new symbols, I’ve been thinking about the various symbol concepts proposed and examples of the last 10 years or so.

What interest is there in evolving the Therion symbol family/environment a little bit?

I’m thinking small incremental steps, not big or complicated changes.

Currently at the local symbol level we have options or properties like:

subtype; scale; outline; orientation (rotation); align; place; visibility ; clip.

These provide a lot of functionality, and generally work well.

But there are things that are missing that I would like to see added to all generic symbols;

• We cannot scale line ornamentation (lines accept a scale, but nothing happens, except for behaviour with min-symbol-scale)
• We cannot arbitrarily add text to any point symbol (I’ve sometimes wanted to label anchor, air-draught, speleothem and other point symbols).  If we could add a text property to every point symbol, then labelling would be more efficient, and the relative alignment would always be good.  This would not replace the dedicated label symbols, just provide more options.
• We cannot add a link (hyperlink) property to symbols.  I would like every point, line, area symbol to have a link property.  These should be able to link to a file system path or to a url.  I’m not sure what options there are in the pdf format/viewers to manage the visibility of links on screen while hiding them in printed output.  Maybe we just have a global switch that makes them visible or not, and compile two maps – one online and one for hardcopy.
• The relationships of the point symbol alignment parameter U: relative to the size and proportions of the symbol are not consistent across all symbols.  This affects the distance that the symbol is moved in each direction when an align is specified.  There are issues for long skinny symbols like speleothems and water-flow as well.
• Align has bugs for some symbols

And then there are global switches/conventions that we apply in layouts;

min-symbol-scale; symbol-show/hide; symbol-colour; symbol-set, to name a few.

Some things that have been proposed at a local symbol level that, that with some global switches, would add useful functionality include:

• Automatic hiding of lines and areas that are smaller than a certain threshold.  This would complement min-symbol-scale for points (but better suited to lines and areas).  An example is described in the wiki https://therion.speleo.sk/wiki/metapost#scale_dependant_visualization_of_symbols
• Creating symbols that are optimised automatically for colour or black and white dependant on whether the user has chosen a switch one way or the other.  Colour variables can be created, and complimentary colour schemes could be created to suite each of the symbol groups.  Users could customise these if they choose to. An example is described in the wiki https://therion.speleo.sk/wiki/metapost#colour_dependant_visualization_of_symbols
• Legend box symbols.  We need better control of these, as Tarquin has recently suggested.  This might also include better symbol aggregation in a single box (ie combining the point, line and area symbol in the same box, or at least not repeating them if the symbols are reasonably similar).

If we were to decide some of these are worth aspiring to, then it would require some agreement as to the structure and type of implementation of a typical generic point, line and area.  Currently most symbols follow a similar pattern, but I suspect we might see some divergence unless we have a pattern to follow.

My metapost and tex skills are definitely limited to ‘copy, paste and meddle’ so it really needs someone with broader skills to progress this.

Some of these suggestions would change the existing behaviour a little, so that is something to consider, with regards to compatibility for existing projects.  I don’t think the impact would be very big in most cases.

Thoughts?

Bruce