Those "C:\CC2\" missing files are unlikely to be an issue, they're probably just some remnant definitions from old times that still is defined, but not used. I doubt Steven would have those either. Same with those "E:\FCW32" references. Sometimes some of those old references decides to hide out in the list of fill style, but it doesn't matter if nothing in the map actually references them.

If you see a red X in the map, use List on it. If it is a symbol reference, it doesn't matter what fill style it has, as you are dealing with missing art for the symbol itself, which should then be checked by opening up the symbol manager, finding the missing symbol in the list there, and hit the list button to get info on the paths of the symbol artwork files, while on the other hand if it is some kind of filled polygon, then the fill style matters, and you can look up the name in the fill style dialog and check the path.

Note that the file structure for CC3+ is exactly the same as for CC3, with one critical difference. While CC3 kept all the data files in it's installation directory along the actual program files, CC3+ instead puts all the data files in a separate directory, C:\ProgramData\Profantasy\CC3Plus by default, insteaf of the installation directory (C:\Program Files (x86)\Profantasy\CC3Plus). You'll find everything you used to find in the installation directory in the data directory.

No, opening and saving doesn't matter. CC3+ doesn't care if you work on a map with a font that currently isn't installed. The text entity will still remember what font it was defined with originally (or changed to if you use change properties on the entity, obviously). But the visual replacement font is just a visual thing when it can't find the font, and it will display the text using Arial instead of the actual font.

Are you sure that that Calligraphic font isn't what you are after? If you don't have it installed, maps will show using Arial, like in my screenshot above, but CC3+ will still list it as the actual font. (Just as in my example above, the text is clearly plain arial, but listed as XXII Arabian-Onenightstand, a font I don't currently have installed, which makes it look very plain indeed until you consider that isn't the font used in the display because I don't have it)

List should provide you with the actual font used. CC3+ uses Arial as a replacement font, so if it shows Calligraphic, that's the actual font used.

See here for an example from my own system where I am missing the font used in the map:

As you can see, it correctly identifies it even if it is displayed using Arial.

There is also another way to see what fonts are defined in a map though, just hit :CC2TSPEC:, the dialog shows all the font referenced from the map. You can't see what font is used for what text from here, and it shows all the fonts defined in the map, which doesn't mean you have actually used them, but it should be enough to help.

This is a bit of a tricky problem.

The issues you see in figure 3 is because multipolies based what their display on the number of overlapping entities. And while a single ellipse on top of a white background will be exactly two entities, so it will generate a hole in the circle, wherever two ellipses overlap, you will have three entities which results in a solid surface at those locations.

Now, as you discovered, cutting and trimming isn't really a solution here. This is because the way CC3+ handles curves. The nodes of a curve does not lie along the curve itself, and arcs do not have nodes at all, they are a result of pure math. If you try to work with wide lines instead, you get other issues because you can't trim to the actual width of a line since that is just a property, the trim hits the center of the line.

I think the attached version should be what you are asking for though. I started from your figure 2 and converted those arcs to smooth lines. It takes a few steps per line to do this, but basically, split it open so it turns into an arch, use line to path on it, split it open again because the last command closes it, and then use straight to smooth on it. This needs to be done on all six lines individually.

Once that is done, you can start trimming them. It can be advantageous to split them in the middle of the intersections before trimming, and after that you can trim using trim to entity, trim to intersection, or just trim and targeting the endpoint of the other line. Generally, if trim to intersection fails (sometimes it does), a simple trim to the endpoint works instead.