How do I convert DOS ANSI (CP 437) files to Unix ANSI with Unicode?

Question

ANSI files from http://blocktronics.org/ seem to be using another ANSI encoding than the one supported in my VT100 terminal emulator.

If I view those files with tetraview, they look decent. But if I view them with less -r the block characters aren't working. If I use iconv -f 437 -t utf-8 | less -r, the block characters work, but the alignment of characters is still messed up. It works in tetraview, so there must be some kind of conversion going on.

I wrote a script to scrape the screen content of tetraview running in tmux, but it's a hack, and I'd like to do the conversion that tetraview does myself.

Can you clarify what you mean by the alignment is still messed up? Additionally what system are you running the iconv on? — theannouncer, Dec 09 '13 at 21:38
@zatch_rulz: iconv is running on Ubuntu Saucy. Here's what I mean when I say the alignment is messed up: http://i.imgur.com/Lf0RF1u.png To the right is tetraview, to the left is iconv output. Both terminals are 80x24. The file in the screenshot is `dman-warrior.ANS` from ACiD Trip — Janus Troelsen, Dec 10 '13 at 09:28
Just to save some time to future readers: tetraview is part of [Tetradraw](http://tetradraw.sourceforge.net/). — Palec, Dec 11 '13 at 10:30

score 3 · Accepted Answer · edited May 23 '17 at 12:14

There are two issues involved:

Encoding needs to be converted from CP 437 to your terminal encoding. This is done using iconv -f 437 input_file.ANS as you already discovered.
ANSI escape sequences need to be fixed.

In dman-warrior.ANS there are two types of escape sequences used. The first one is used only once and is the first thing in the file. It is ESC[0m and it resets all graphics mode attributes. The second type is ESC[<value>C (e.g. ESC[24C) and it moves the cursor <value> characters forward (to the right). If the cursor cannot go any further, it stops. You can test it in your terminal using this shell command:

printf '\x1b[10000CXYZ\n'

It should look like this:

|$ printf '\x1b[10000CXYZ\n'              |
|                                        X|
|YZ                                       |
|$                                        |

The image file has only a few lines (delimited by CRLF). Each is wrapped to the terminal width (80 columns), thus producing several screen lines.

The image is OK up to the first screen line starting with ESC[<value>C escape sequence in the middle of a file line.

Terminal writes the previous screen line, ending at the last column.
The ESC[<value>C escape sequence is met. Being at the last column, cursor cannot go any further to the right, so the sequence is ignored.
Next comes a character which forces the line to be wrapped and is printed on the following screen line.

The new screen line is missing the empty space which should have been skipped by the escape sequence.

Possible solutions

Somehow alter the behavior of the terminal emulator. (I have no idea how, except compiling a tweaked custom version.)
Explicitly break lines. If the ESC[<value>C is the only escape sequence used, it should by easy enough to write a program that fixes the images.

score 2 · Answer 2 · answered Dec 10 '13 at 17:32

2

These files are all of type "Ansimation" which relies on a certain screen width and height to display it. Your terminal probably doesn't have the correct width.

answered Dec 10 '13 at 17:32

littleimp

1,159
9
13

My terminal has the standard size 80x24. Since that is the standard width for DOS too, and tetraview successfully displays the image in a terminal like that, I don't think that's the problem. – Janus Troelsen Dec 11 '13 at 13:28

score 2 · Answer 3 · answered Dec 31 '18 at 06:33

Littleimp's answer was somewhat correct.

Many ANSI art pieces are designed for terminal sizes wider than the standard 80-column of the day. Janus is incorrect that this art is only made for 80-columns. A careful visual inspection would have revealed that some use use far more characters per line.

Unlike most standard text files, many ANSI artfiles do /not/ contain CR or CR/LF to terminate the end of every line, but rather allow the terminal to wrap to the next line for them. This gives them use of the full columns of the terminal, e.g. 80 or 132, without having to CRLF before end of line, making the maximum width 79 or 131.

So for e.g. blocktronicks goo-b7.ans will not display correctly in any terminal besides 160 characters wide.

I have illustrated this on a sample ANSI picture here: https://i.imgur.com/WBJ8xfs.png

The standard sed/awk tricks for inserting a Carriage-Return after every X characters won't work, since short lines terminated with CR/LF will not be skipped, but rather subtracted from the next line's length before a CR is inserted at an inappropriate place.

To convert these files to something saner, one would need a program/script that steps through each line, only inserting a CR when a line is found with maximum line length.

score 0 · Answer 4 · answered Dec 10 '13 at 19:08

0

I was looking online and I found an automatic converter that you donot have to install. http://www.gofunnow.com/convertutf8/convertutf8.php?destencoding=-2#.UqdmkifMrAk

answered Dec 10 '13 at 19:08

GJH105775

45
9

That site is using another definition of "ANSI", they are just referring to CP-1251, probably. Anyway, this offers no advantage over iconv. – Janus Troelsen Dec 11 '13 at 13:29

How do I convert DOS ANSI (CP 437) files to Unix ANSI with Unicode?

4 Answers4