Why don't we use the escape code directly? FTL should be able to sending everything through the API, cfm. excerpt from what is sent to the browser:

00000000  0d 1b 5b 4b 20 20 5b e2  9c 93 5d 20 44 4e 53 20  |..[K  [...] DNS |
00000010  72 65 73 6f 6c 75 74 69  6f 6e 20 69 73 20 61 76  |resolution is av|
00000020  61 69 6c 61 62 6c 65 0a  0a 20 20 5b 69 5d 20 4e  |ailable..  [i] N|
00000030  65 75 74 72 69 6e 6f 20  65 6d 69 73 73 69 6f 6e  |eutrino emission|
00000040  73 20 64 65 74 65 63 74  65 64 2e 2e 2e 0a 0a 20  |s detected..... |
00000050  20 5b 69 5d 20 50 72 65  70 61 72 69 6e 67 20 6e  | [i] Preparing n|
00000060  65 77 20 67 72 61 76 69  74 79 20 64 61 74 61 62  |ew gravity datab|
00000070  61 73 65 2e 2e 2e 0d 1b  5b 4b 20 20 5b e2 9c 93  |ase.....[K  [...|
00000080  5d 20 50 72 65 70 61 72  69 6e 67 20 6e 65 77 20  |] Preparing new |
00000090  67 72 61 76 69 74 79 20  64 61 74 61 62 61 73 65  |gravity database|
000000a0  0a 20 20 5b 69 5d 20 43  72 65 61 74 69 6e 67 20  |.  [i] Creating |
000000b0  6e 65 77 20 67 72 61 76  69 74 79 20 64 61 74 61  |new gravity data|
000000c0  62 61 73 65 73 2e 2e 2e  0d 1b 5b 4b 20 20 5b e2  |bases.....[K  [.|
000000d0  9c 93 5d 20 43 72 65 61  74 69 6e 67 20 6e 65 77  |..] Creating new|
...

0d 1b 5b 4b, for instance, is the binary code for OVER from COL_TABLE:

$ source /etc/.pihole/advanced/Scripts/COL_TABLE

$ echo -en "$OVER" | hexdump -C
00000000  0d 1b 5b 4b                                       |..[K|
00000004

(see that this matches 100% the first four bytes in the stream excerpt above!)

Just saying this as there is also bold bold text in the output plus maybe some colors when FTL finds an error in the lists (but I may be misremembering this one). It is kind of odd that OVER gets through but not the others. Any objections against always sending all the escape sequences over the API?

Why don't we use the escape code directly? FTL should be able to sending everything through the API, cfm. excerpt from what is sent to the browser:

The issue is: we only send color escape codes via COL_TABLE if there is an terminal connected which is able to display colors. This is not the case case if piped via FTL. (Check the link to COL_TABLE, OVER is not guarded)
If we remove the check and always send the codes we end up with

We would need to replace those characters with the relevant CSS class. This is what #3191 did.
The main question is: do we want to always send the color codes even if there is no terminal capable if interpreting them? This could cause issues with users also using the COL_TABLE for other things.

Just saying this as there is also bold bold text in the output plus maybe some colors when FTL finds an error in the lists (but I may be misremembering this one).

You are correct, but I did not want check for all possible replacement text, this will break earlier or later. I just went for the text/symbols that should stay constant

In v5 gravity was never in colors.

we only send color escape codes via COL_TABLE if there is an terminal connected

In v5 we sent the color codes in 2 cases:

• if there was a terminal or
• if the variable WEBCALL was set (this was only set when generating the Debug log via PHP).

We decided to change a bit more. Together with pi-hole/pi-hole#6314 and pi-hole/FTL#2538 all escape sequences are send to the web interface and this PR translates them to the corresponding CSS classes

Idea: We could use a counter here - for each <span> we create we increment the counter by one. Once we see COL_NC, we know how many </span>s we have to add (and reset the counter to 0).

AI refactored code, so untested but you get the idea.

// Track the number of opening <span> tags inserted.
let spanCount = 0;

// Mapping of ANSI escape codes to their corresponding CSS class names.
const ansiMappings = {
  "\x1b[1m": "text-bold",
  "\x1b[90m": "log-gray",
  "\x1b[91m": "log-red",
  "\x1b[32m": "log-green",
  "\x1b[33m": "log-yellow",
  "\x1b[94m": "log-blue",
  "\x1b[95m": "log-purple",
  "\x1b[96m": "log-cyan"
};

// Replace each ANSI escape code with its corresponding HTML tag.
for (const [ansiCode, cssClass] of Object.entries(ansiMappings)) {
  line = line.replaceAll(ansiCode, () => {
    spanCount++;
    return `<span class="${cssClass}">`;
  });
}

// Replace the ANSI reset code with the correct number of closing </span> tags.
line = line.replaceAll("\x1b[0m", "</span>".repeat(spanCount));

The for loop is a must have IMHO.

I think this is the right approach: replacing sequentially to always add the correct number of closing </span>, regardless of how many opening <span> we encounter.
In the bash script we could have

${COL_BOLD}${COL_GREEN}TextText${COL_NC}, more Text ${COL_BOLD}bold section${COL_NC} even more.