I am trying to use the Symbol font for numbers so that the dash - is interpreted as a proper minus sign (as using a dash instead of a minus sign is one of my pet peeves). I somehow thought that used to work, but now I am getting an up arrow instead.
gives the attached result, i.e. I can get a minus sign with \055 in regular or Symbol font, but @~-@~ gives the up error. How should I go about automating number output to have proper minus signs, besides replacing “-” with \055, which I’d be happy to, but it seems there is something simpler I am missing?
something happens when PS_CHAR_ENCODING=ISOLatin1+ which is the likely default:
echo 0 0 18 0 0 CM "- \055 @~-@~ @~\055@~" | gmt text -R-1/1/-1/1 -JX5 -png quick --PS_CHAR_ENCODING=ISOLatin1+
all is good if PS_CHAR_ENCODING=Standard+, Symbol minus is exactly the \055 minus:
echo 0 0 18 0 0 CM "- \055 @~-@~ @~\055@~" | gmt text -R-1/1/-1/1 -JX5 -png quick --PS_CHAR_ENCODING=Standard+
that arrow has octal code 255 (0xad) in Symbol font, while octal 255 (0xad) in ISOLatin1+ is some special sort of hyphen according to ISO/IEC 8859-1 - Wikipedia
\255-\055 = decimal 128 = 2^7, that is, binary difference is that single bit. I have no idea on why/how that extra bit gets set and why only if PS_CHAR_ENCODING=ISOLatin1+
GMT has quite a hostile API, but I keep on using it because it produces the best results, it’s not even close, I’d think quite a few GMT users think the same way, and then you go and mess that up with sloppy typography? Absolutely not.
I would like to know a bit more about this. Complicated it is and we can’t change it, but maybe we can create new, simpler, API functions. But need more detailed feedback.
EDIT: NOTE, the API is this. Is it what you where referring to?
By hostile I mean no disrespect, but it does take quite a bit of work to set-up each layer, there are so many options and quite convoluted ways that one enables them in the GMT command-line, there’s going to be some time checking that manual for that. It’s time well-spent considering the quality of the output in my view. As to changing it, that sounds like a big job. I find myself liking long options, and in scripts go multiline
bit more readable, and could be done in a backward-compatible fashion. The GMT command-line parser is custom as I recall, I’d expect that extending it to use long options would be a pig of a job; I can’t volunteer for that I’m afraid (too much on), so it would be ill-mannered of me to ask someone else to
Re “API”, I was meaning the command-line interface.
does any of these two things (GMT.lj and the long options) solve something like typesetting issue in this topic?
pyGMT solves typesetting to a limited extent, but personally I don’t like learning pyGMT’s long options (why would I like learning long options after learning the short ones?), and I don’t like their idea to disable the use of short options in the future. My salvation so far been the possibility to call GMT modules via pyGMT’s session.call_module mechanism.
Maybe, but I honestly did not payed much attention to this issue that seems to resolved by using the appropriate PS fonts. My reply was in regard jjg’s comment on hostile GMT syntax.
Regarding the PyGMT choice, as I had opportunity to say in other occasions, I fully agree with you and I think they are making a big mistake. In GMT.jl one can either use long options or short. e.g. all these work R="0/10/0/20", or region=(0,10,0,20), or region="0/10/0/20", or R=[0,10,0,20], or …
Sure, GMT CLI syntax has always been hard to learn. Plus GMT is a complex tool for solving complex tasks, so the users really need to know what they are doing. All this makes learning extra hard, all for good reasons. Once learnt, GMT CLI syntax is very concise and powerful esp when combined with the modern one-liner capability. I sometimes find myself irritated once unable to achieve something with a one-liner that looks definitely doable, due to a lack of understanding on my side or in case of hitting a bug.
PyGMT’s session.call_module only accepts the standard GMT CLI options as it calls GMT modules directly, plus the PyGMT guys developed excellent “virtual file” helpers for feeding data from python memory into GMT. Even shell-like pipelining can be done! So as long as session.call_module is exposed I don’t need to care about the long options if I don’t want to and can keep calling GMT the way I like - plus having access to the PyGMT’s extras like tilemap or text (better typesetting).
