Support "dim"/"faint" modifier

[nwalters512]

Consider the following code:

const chalk = require('chalk')
const { default: AnsiUp } = require('ansi_up');

const ansiUp = new AnsiUp();
console.log(ansiUp.ansi_to_html(chalk.dim('testing')));

Per the "SGR" section where $n = 2$ on https://en.wikipedia.org/wiki/ANSI_escape_code, the modifier in use here is defined as "Faint, decreased intensity, or dim". I would expect this to render as something like either of the following:

<span style="filter:brightness(0.7)">testing</span>
<span style="opacity:0.7">testing</span>

However, it just prints the string testing, indicating that this library doesn't support this modifier.

I'd be willing to open a PR if you'd accept one!

For reference, here's how a few other similar libraries implement this:

• https://github.com/Aloso/to-html/blob/4b427d59d986a937795d337a0e40d524c578cf50/crates/ansi-to-html/src/html/mod.rs#L23
• https://github.com/rburns/ansi-to-html/pull/44/files (note that this was later reverted, see faint text feature causes text to be unreadable rburns/ansi-to-html#45 - maybe this is more complex than it looks on the surface?)

[drudru]

Hi. Just thinking out loud.

We currently handle bold as 'font-weight: bold' for that span.
The Wikipedia page is stating that faint/dim should be handled as a font-weight.
If we do that, this becomes a tri-state for the font-weight, not too difficult.

If we have to set the CSS to a filter or opacity, that is also, ok, but could be configured as a non default option.

@nwalters512 - How does that sound?

[silverwind]

I guess I would also prefer font weight. BTW, are there equvialent CSS classes for font-weight? The example does not show any.

[drudru]

Lets go with font weight and add the classes to the example.
This will go into the next major release.

[nwalters512]

I don't love doing this with font weight, as that doesn't align with how the other terminals I have access to display text with the dim/faint modifier.

Here's the macOS terminal:

And here's iTerm 2:

Each of them are distinguished by a dimmer apparent color, not a different weight.

[silverwind]

If color manipulation can be done cleanly, e.g. no filter (which causes fringe issues, but could maybe be worked around using mix-blend-mode), and no opacity (does not work on non-opaque background), I guess I do have a preference for it too.

The ideal way to do it is with the brand-new color-mix, but it may be too new to use. Personally, I don't care as I'll not be using the built-in styles but style via classes where I can decide myself whether to use color-mix.

[drudru]

Released

[silverwind]

For some reason, I see no difference on SGR 2 using v6.0.0:

HTML rendering:

Same rendering in iTerm2 (bold is disabled in my settings):

Output was produced with this:

curl -sL https://gist.github.com/lilydjwg/fdeaf79e921c2f413f44b6f613f6ad53/raw/94d8b2be62657e96488038b0e547e3009ed87d40/colors.py | python3

[drudru]

@silverwind - just saw this in my email. Sorry. I will look at your examples.

[silverwind]

Thanks, besides SGR2, SGR7 and SGR8 and the whole second row except SGR21 and hyperlink in the example could be improved. Maybe do it like iTerm and never output unknown escape sequences, which imho are never useful in a rendering.