rburns/ansi-to-html

Cyan color preventing `<b>` tag from getting closed correctly

Closed this issue · 5 comments

raine commented

This issue is going to be vague because I'm not sure what exactly is going but I can demonstrate the bug.

I'm using cli-table3 to generate a table with the styles cyan and bold for the header row.

With both of those styles, this output is generated for the header line:

'\u001b[90m│\u001b[39m\u001b[1m\u001b[36m name             \u001b[39m\u001b[22m\u001b[90m│\u001b[39m'

<span style="color:#555">│<span style="color:#FFF"><b><span style="color:#0AA"> name             <span style="color:#FFF"><span style="color:#555">│<span style="color:#FFF"></span></span></span></span></b></span></span>

What to me appears to be relevant here, is that the <b> tag is not closed until the end, even though \u001b[22m appears right after the word name.

Now look at the same output, except with the cyan style removed:

'\u001b[90m│\u001b[39m\u001b[1m name             \u001b[22m\u001b[90m│\u001b[39m'

<span style="color:#555">│<span style="color:#FFF"><b> name             </b><span style="color:#555">│<span style="color:#FFF"></span></span></span></span>

Now, <b> is closed right after the word name.

Hopefully this made sense.

Also, if you have npx installed, you can see the bug in action in my project with this:

echo '[{"foo":1,"bar":2},{"foo":2,"bar":1}]' | npx ramda-cli@5.2.1 -I -o table
raine commented

Just after opening this issue, I realized that flipping the order in which color styles are applied to the header texts fixes the issue. It appears that doing cyan before bold is causing the problem here. Not sure if there still is a bug in ansi-to-html, though.

raine/ramda-cli@487010e

rburns commented

It appears to me that the 22 escaped code may be ignored as the previous opening bold tag is not on the top of the stack. https://github.com/rburns/ansi-to-html/blob/master/src/ansi_to_html.js#L149 https://github.com/rburns/ansi-to-html/blob/master/src/ansi_to_html.js#L299

the trailing close bold tag is on account of closing the remaining tags in the stack.

I've been trying to come up with a small test case which demonstrates that's what's happening. no luck yet.

In general, interpreting 22 as <span style="font-weight: normal"> instead of </b> might be a better approach.

rburns commented

this looks about right.

with the current release

convert.toHtml('\x1b[1m\x1b[36mname\x1b[22m|')

will produce

<b><span style="color:#0AA">name|</span></b>

which leaves the '|' erroneously bold.

Can you test the code on this branch, and see if it gives better results: https://github.com/rburns/ansi-to-html/pull/50/files

raine commented

Thanks @rburns.

Those changes appear to work as well.

With this, I wonder if it would make sense to change the starting <b> to a span element with a bold style.

rburns commented

for consistencies sake, it would probably make sense to use a style attribute instead of a bold tag. But, in the interest of not changing something that works, I'd probably lean towards leaving it as it is.

The relevance of the using the style attribute for 'normal' text is that there isn't a <normal> tag, in the way that there is a <bold> tag. The previous solution used a </bold> tag to emulate <normal>, which is context sensitive, and led to the bug.

Similarly, these https://github.com/rburns/ansi-to-html/blob/master/src/ansi_to_html.js#L150-L151 might better be implemented with font-style and text-decoration css properties.

But, this appears to fix this issue, so I'll merge it before making more changes.