This can only be changed by editing the drawing tool (Or better, make a copy, and edit the copy).

But, the best way to do it is to utilize a proper sheet naming scheme.

Almost all drawing tools look for sheets that STARTS with something in particular, for example, a drawing tool for the outside sheet will be set to draw on OUTSIDE*. That * is a wildcard, and means anything that starts with the text preceding it.

So, if the drawing tool is set to draw on OUTSIDE*, if your current sheet is called OUTSIDE VEGETATION for example, it will happily use that sheet instead of the default outside sheet. On the other hand, if your current sheet do NOT start with OUTSIDE, it will allways go to the default OUTSIDE sheet even if you have others starting with the word.

This same behavior applies to symbols as well.

Did you add that line of yours near those lights too? When exporting, CC3+ exports the map in sections, and it can't "see" what's outside the current section. I am guessing it is the same strange issue as above, and there isn't a "fix" in the section those lights happen to lie in.

Unfortunately, you can't make the background transparent, you'll have to do that in post-processing in another program. And if you plan to do that, your anti-alias should be off, since antialiasing is the sworn enemy of proper background removal. Also, antialiasing off will let the map export faster.

If you are going to convert it to a jpg anyway, you shouldn't worry about the file size of the png though, since that won't really matter in the end anyway. png's are always quite a bit larger than jpeg's.

The scale symbols are always made to be placed with scale factor 1.0, because it is important to get those absolutely correct, and using a factor of 1.0 makes the precision perfect.

Most other symbols are designed for an imperial scale, and are then simply scaled down when used in metric maps through the default symbol scale for the map.

Yea, basically the same as I foun, just about any solid entity will work, but the entity have to be within view, so since exports are done in multiple passes, you won't necessarily need one line per symbol, but there must be one within view for each segment of the export.

One thing I didn't try yet, but which may work is just making that part of the symbol. A symbol can contain entities in addition to the image. Of course, those entities would be part of the symbol and get the same effects.

I've notified the developer, maybe he can give some more insight in exactly what is happening here.