Using a symbol in the typesetting database

[Atarimaster]

Hello,

currently I’m trying to replace Geocart’s city point with a different symbol, but I keep failing.
(Geocart 3.2.1 on OS X El Capitan)

The idea was to use a different symbol, preferably the unicode character 'BLACK SQUARE' (U+25A0) ■ for capitals, while other cities are marked with Geocart’s city point. I also tried other characters.

I made sure that the typesetting database is saved using UTF-8 encoding and the fonts I tried contain the character that I’ve used in the typesetting database.
Sometimes (e.g. when I tried the DejaVu Sans font), the symbol seems to be right in Geocart, but when I export that document to a PDF file, the symbol is missing (although the names of the cities are there). When I open the PDF with PhotoLine or Affinity Designer, I can see that the document doesn’t even contain the layers that usually hold the city point.
On some fonts that come with macOS it looks good in Geocart, too… but when I try to export, I get the message
»A font used in a typeset database is unsupported for PDF output. (Fonts must be .TTF or .OTF; please see "Available Fonts" in the Help menu)« for AppleGothic (although it is listed in the available fonts), or »A font used in a typeset database has an unrecognizable structure and is possibly corrupt« for the font Symbol.

I’ve tried some other characters which are within the plain ASCII range (e.g. the full stop or the asterisk) but in that case, the city point is not the correct location. I understand the reason for this, I’m just mentioning it for the sake of completeness.

So, is there any combination of font/symbol that is known to work?


Moreover, here’s a suggestion which actually belongs into the »Wish List« board but I’m posting it here because it’s related to the problem described above:
It’d be nice if instead of noting a symbol font and character in the typeset database, you could note a path to a SVG file which is used for the symbol, plus the size at which it is to be rendered in the map. I’ve got no suggestion for the actual syntax in the database or the unit that is used for the size – because frankly, I don’t care. Whatever you come up with, I’ll adjust.


Kind regards,
Tobias

[daan]

I’ve never been happy with the font support. I use a third-party library for PDF generation, and another one for font handling. They’re buggy, difficult to debug into, and the toils of integrating them into Geocart were so vexing (and required so many fixes to the libraries) that I’ve been loath to update them. I also don’t know if updating them would improve the situation.

This is something I should revisit, given how inconsistently and unpredictably text placement works and exports.

I guess my only suggestion for now is to use a simpler, common symbol and replace it in your graphics editor, if that’s easy to do.

Sorry for the trouble.
— daan

[Atarimaster]

I guess my only suggestion for now is to use a simpler, common symbol and replace it in your graphics editor, if that’s easy to do.

Good idea, but … *grmpf*
I just tried that and it’s not that easy. Because different characters might have a different left/right sidebearing (in case you’re not familiar with typographic terms, see first entry of this glossary), the symbol changes its position when you replace it. Only a bit, but too much for my idea of precision.

So for now, I think I’m going to stick to the way I did it before:
– Create two different typesetting databases, one with capitals and one with the other cities;
– use the Geocart city point on both;
– in the graphics editor, select all city points of the "capitals" layer, and change his styling (e.g. use a different color or add a border or something).

For continental maps or maps of even smaller regions, it also might be feasible to carefully place another symbol right on top the city point, but of course that’s a LOT of work on world maps.

Thanks anyway!
Kind regards,
Tobias

[daan]

I brought down the latest source code for the library that handles PDF document construction, added back into it all the changes I had made to the original library, and tried that. No difference in behavior. This was no surprise to me because it was clear that no work had been put into font handling in the last 9 years.

The reason you’re having trouble with that symbol is that PDF doesn’t actually have any concept of Unicode. There are ways to get a Unicode character into a PDF document, but the library I use, as written, only handles named encodings. It looks like I can probably extend the library to include “MacExpertEncoding” without a lot of difficulty but just a lot of tedium. That’s probably a good idea. However, that encoding doesn’t have many symbols. There is a Symbol encoding and a dingbats encoding, both of which would be useful for maps, but they don’t seem to be one of the named encodings. They may only apply to the Symbol and ZapfDingbats fonts; that part is not clear to me yet, but I don’t think I can use those in general.

Trying to get the library to embed arbitrary characters from arbitrary fonts is just an overwhelming prospect.

— daan

[Delozier]

I brought down the latest source code for the library that handles PDF document construction, added back into it all the changes I had made to the original library, and tried that. No difference in behavior. This was no surprise to me because it was clear that no work had been put into font handling in the last 9 years.

The reason you’re having trouble with that symbol is that PDF doesn’t actually have any concept of Unicode. There are ways to get a Unicode character into a PDF document, but the library I use, as written, only handles named encodings. It looks like I can probably extend the library to include “MacExpertEncoding” without a lot of difficulty but just a lot of tedium. That’s probably a good idea. However, that encoding doesn’t have many symbols. There is a Symbol encoding and a dingbats encoding, both of which would be useful for maps, but they don’t seem to be one of the named encodings. They may only apply to the Symbol and ZapfDingbats fonts; that part is not clear to me yet, but I don’t think I can use those in general.

Trying to get the library to embed arbitrary characters from arbitrary fonts is just an overwhelming prospect.

— daan

I guess if this is too complicated and/or time-consuming for someone like you, I don't stand a chance in getting this to work. I'm so frustrated with PDF...

[daan]

I guess if this is too complicated and/or time-consuming for someone like you, I don't stand a chance in getting this to work. I'm so frustrated with PDF...

What is it that you are trying to do?

— daan

[Atarimaster]

By the way, daan, did you ever explore the option to add SVG export to Geocart?

Theoretically, I think it should be possible to come up with a SVG file that’s in now way inferior to a PDF file… well, maybe in one way (see below). At least, it should handle Unicode characters properly. The downside is that according to my tests the SVG import abilities of graphics applications seem to vary quite a bit. So maybe it’d be just replacing old obstacles with all-new, all-different obstacles…

The one thing that, to my knowledge, SVG is lacking is a proper font embedding. However for me it’d be enough if Geocart just exports the font references in the SVG file. After all, as long as the file is post-processed on the same computer, the graphics application has access to the same fonts as Geocart does.

Kind regards,
Tobias

[daan]

By the way, daan, did you ever explore the option to add SVG export to Geocart?

No. I should. I use Cairographics for my rendering, but I have PDF export going through LibHaru. I don’t recall why I didn’t (or couldn’t) use Cairographics directly for export. Maybe those reasons are gone now. Cairo does export SVG.

— daan

[Atarimaster]

I use Cairographics for my rendering, but I have PDF export going through LibHaru. I don’t recall why I didn’t (or couldn’t) use Cairographics directly for export. Maybe those reasons are gone now. Cairo does export SVG.

That sounds great, not like an insuperable task. Of course I know that the devil’s in the details…

[daan]

I have replaced the PDF export engine with PoDoFo. The font handling is better, I find, but not ideal. Like before, it’s restricted to TrueType for embedding, and even without embedding, it’s not great with CFF-based. It’s also only Unicode, so any symbols you might want will have to be within the Unicode répertoire. East Asian writing scripts work insofar as the glyphs are encoded in Unicode and the font is TrueType.

— daan