Fix auto-legend using wrong symbol for -Sf fault decorations (#9066)

[Esteban82]

Done by Claude Sonnet 5

Test by Claude:

Problem

When plotting fault/front symbols with plot -Sf<gap>+<type>+<sense>
and requesting an auto-legend entry with -l"label", every legend
entry was drawn as a box, regardless of the actual front type
requested (box/circle/fault/slip/triangle/inverted-triangle):

gmt begin lixo png
    gmt plot @CA_fault_data.txt -Sf0.5+b+r -l"box"
    gmt plot @CA_fault_data.txt -Sf0.5+c+r -l"circle"
    gmt plot @CA_fault_data.txt -Sf0.5+f+r -l"fault"
    gmt plot @CA_fault_data.txt -Sf0.5+s+r -l"slip"
    gmt plot @CA_fault_data.txt -Sf0.5+t+r -l"triangle"
    gmt plot @CA_fault_data.txt -Sf0.5+v+r -l"inverted triangle"
gmt end

The symbols on the map itself were plotted correctly; only the
auto-legend was affected.

Root cause

gmt_add_legend_item() in gmt_init.c writes one line per legend
entry to a hidden legend info file. For a front symbol
(S->symbol == GMT_SYMBOL_FRONT, i.e. 'f'), the code fell through
to the generic branch that only writes the bare symbol character:

fprintf (fp, "S - %c %s %s %s - %s\n", symbol, ...);

This drops the front sub-type (S->f.f_symbol) and sense
(S->f.f_sense) that were parsed from +b/+c/+f/+s/+t/+v and
+l/+r. When pslegend.c later reads this entry, it looks for a
+ modifier on the symbol code:

if ((c = strchr (symbol, '+')) != NULL)
    strcpy (sub, c);
else
    sprintf (sub, PSLEGEND_FRONT_SYMBOL);  /* "+l+b" */

Since no + was ever written, it always falls back to the default
PSLEGEND_FRONT_SYMBOL ("+l+b", i.e. a box to the left), which is
exactly the symptom reported.

Fix

Add a dedicated branch for GMT_SYMBOL_FRONT in
gmt_add_legend_item() that reconstructs the +<type>[+l|+r]
modifier string from S->f.f_symbol / S->f.f_sense before writing
the legend entry, mirroring the existing special-cased handling for
quoted lines ('q') and decorated lines ('~') just above it.

No changes were needed in pslegend.c: it already parses +
modifiers on front symbols correctly, it just never received them.

Testing

I got this figure now:

Fixes #9066

[joa-quim]

One thing I don't understand in this example (didn't get either when the issue was open) is why the plotted lines look like they look. I only see a mess of incomprehensible symbols. Is that the expected thing? And shouldn't the symbols in legend be filled too?

[Esteban82]

Don't pay attention to the figure. Just look at the legend. Before the PR, the same symbol (a square) was drawn for all cases of the different -Sf. With the PR, each symbol is now drawn correctly.

About the color. Yes, I think they should be filled. I'll look into that.

[Esteban82]

There was no problem with the infill. However, I found another bug that can be tested with this script:

cat << EOF > t1.txt
0 1
1 1
EOF
cat << EOF > t2.txt
0 2
1 2
EOF
gmt begin plot png
    gmt basemap -R0/1/0/5 -JX5c -Bf
    gmt plot -Wthick,red -Gblack  -Sf2+c+r t2.txt -l"circle thick"
    gmt plot             -Gpurple -Sf2+b+r t3.txt -l"box"
gmt end 
rm t*.txt

Now, with the last commit you should get this figure.

Without the latest commit, the line for "box" in the legend is plotted with the same properties as the previous line (i.e., thick red).

Based on the changes suggested by Claude Sonnet 5, I understand that something similar was happening with the quoted and decorated lines.