GenericMappingTools / GenericMappingTools/gmt
Fonts in GMT
- Dominant language
- C
- Stars
- 979
- Forks
- 414
- Avg merge
- 17h 26m
- Merged PRs (30d)
- 54
Description
The current scheme of working with fonts used in the GMT has, in my opinion, the following disadvantages:
1. Encoding. The encoding is hardcoded when the program starts and cannot be changed in a line of text, such as a font or fontsize. This is probably not a very big problem, since they rarely encounter it.
2. Encoding. All encoding vectors are hardcoded into the code. You can neither change them, nor substitute yours. This closes up some very interesting possibilities, such as the use of bold Symbol typeface based on glyphs from, for example, DejaVu fonts. Of course, since we are dealing with Postscript, adding code there after the drawing is not a problem. But this is a dirty hack.
3. Encoding. Some hardcoded encoding vectors do not work in part or in whole, with standard fonts as well as external fonts. On my Linux system with ghostscript-9.53.3 the following vectors have problems:
- ISO-8859-2. F0 and FE (dbar and tcedilla) are unvailable. Didn't check if the required glyphs are in the fonts, but under different names.
- ISO-8859-3. A1, B1, BF, E5 and F5. Also didn't check glyphs.
- ISO-8859-3. A2, BB, F0.
- ISO-8859-6. All characters in the upper half of the vector are missing, except A0, A4 and AD.
- ISO-8859-7. All characters in the upper half of the vector are missing, except A0-B4, B7, BB and BD. But Greek letters are definitely present in standard fonts, but they are named differently, not afiixxxx. That is, this is an encoding problem, not a font.
- ISO-8859-7. E0-FA.
Some of the listed vectors work with the DejaVu font, but not with Noto. Glyph naming is different. I can give scripts to check and the results obtained if interested.
Suggested solutions
1. I don't know why this problem has not been resolved until now. Postscript allows you to have the same font with different encoding vectors, under different names, of course. It is possible to generate a set of fonts with all possible encodings statically, in the prologue, or dynamically when the font is actually used. I would suggest making the PS_CHAR_ENCODING a list and adding a @-switch to select the encoding. Based on this solution, it is possible in the future to make it possible to use Unicode for the input text.
2. Custom fonts are available to the GMT, I don't think custom encodings are a big problem.
3. I think it is necessary to update the encoding vectors supplied with GMT. I wrote a script (very ugly) that, using the available font and unicode encoding vector, makes the PostScript encoding vectors, so I can help with this work if necessary.
Contributor guide
Assessment
This issue has not been assessed yet.