Strip color codes for ascii length calc

[fydo]

Ascii images with lots of color codes would result in too large of a gap between the image and information. This uses a function to strip out color codes during the routine that determines ascii_len (and ultimately, text_padding) for ascii images.

[dylanaraps]

Can I see what kind of ascii you're trying to use?

[fydo]

Certainly! I've uploaded an example here:

https://fydo.net/misc/fydo.asc

[dylanaraps]

Neofetch doesn't support ascii files with embedded colors. Instead the colors are defined like this:

${c6}  .--.---.
 ( \\'--'/ )
( '..-...' )
 '.'-._.'.'
${c1}  <'-.,.->
     `\(  _
      <\\ / \
     __ \\|_/
    /  \\ \\
     '--'.\\ >
           \\

I'll look into a simpler method of stripping the escape characters.

[fydo]

I did see that way of defining the colors in the documentation (and being able to re-assign the color numbers at runtime is great) but it does lack the ability to provide background colors or do other fancy stuff like bold or italic escape codes.

Please let me know if you need anything else from me for this pull request. Thank you!

[konimex]

but it does lack the ability to provide background colors or do other fancy stuff like bold or italic escape codes.

For background color, I think you can modify color() (or add a new function like bcolor() which deals exclusively with background colors, whichever you prefer) in your PR, adding your own case like printf '\e[48;5;%bm' "$1" and then set it in set_colors() like b1="$(bcolor "$1")" or something like that.

[fydo]

I see this pull request was closed. Was this issue ever resolved? I see v6.1.0 is still exhibiting the issue where ascii color codes are causing the right info box to shift to the right (in some cases even off of the console window) due to the incorrect length calculation. Thanks in advance.