Line length parameter for IRC dump about ansiart2utf8 HOT 8 CLOSED

@Underdoge,

Now that I have a user, that will probably light a fire under me to handle all of the ESC codes properly. I'll see what I can do about the IRC issue. Thanks!

JS

from ansiart2utf8.

I'm not an IRC user, so I'm not entirely sure I understand the problem. It has a -w parameter for setting the wrap length (defaults to 80 since that is what most ANSI art wrapped at).

One deficiency that I know the program has is dealing with relative motion escape codes. I think it already handles forward-jumping ones, but makes no attempt at backward-jumps. Most ANSI paint programs don't use backward-jumps in their output anyway, but if you run into a hand-coded ANSI file (especially ones that do animations, like on textfiles.com), they do have backward-jumps, and the ansiart2utf8 output will be incorrect.

from ansiart2utf8.

By line length, do you mean a horizontal truncation?

from ansiart2utf8.

Thanks for the quick reply @BourgeoisBear! Yes I meant horizontal truncation.

I think the problem I'm seeing is due to a limitation in IRC's standard which only allows 510 raw characters per line, which are easily exceeded with the regular UTF output.

For example one of my favorite ANSI Blocktronics-WTF4_Megajoint.ans renders beautifully in the console with the script as it currently is, but when trying to output it directly in IRC the lines get truncated by IRC's line limit as seen here.

As I said this is definitely a limitation in IRC's standard, but it would be nice to see it working there too. The IRC standard in terms of formatting is entirely a different animal. For the most part in IRC you need to save characters by only stating colors when the color changes, like some sort of compression.

Maybe I'll take a stab at it when I have some free time.

By the way thanks for this script, it is awesome!

from ansiart2utf8.

@Underdoge,

Do you have a preference for handling the truncation? Even in the terminal, each color-change is triggered by an escape sequence which is at least two characters, so for a "fixed" width graphic the per-line byte-lengths are all over the place (number of color-changes / ratio of of plain ASCII chars to UTF-8 translated box-drawing chars / etc).

Two approaches I can think of:

• Best Effort: Render as many characters-per-line as possible up to 510 chars. More of the image would be rendered, but may have a jagged right-edge.

• Uniform Width: Pre-calculate worst-case for a visible column that fits in 510 bytes. Render only up to that column. Uniform width, but less of the image may be rendered.

In both cases, ensure that the escape-code-state at the truncated newline matches that of the original newline.

from ansiart2utf8.

Best Effort I think would better in my opinion.

Also I've been working on something like this myself, forking another script I found here.

My version is not perfect but it might give you some ideas.

Honestly I've been having a hard time getting used to this script's architecture and language (Perl) so I'm thinking of redoing it in javascript.

from ansiart2utf8.

C is my "go-to" language for things like this, but its UTF-8 handling leaves something to be desired. I knew that Go had solid UTF-8 support, so I went with that. Not entirely satisfied with the fat binary though!

I've heard that Rust also has strong UTF-8 support. If it makes a smaller binary, I may swap it all over to Rust.

from ansiart2utf8.

@Underdoge ,

I've added a best-effort per-line byte-truncation with the -bytes parameter in release-0.3b. Let me know if this fixes your problem.

Thx.

JS

from ansiart2utf8.