Line endings for macOS/Unix terminals: A 29-row ansi art has only 6-rows on macOS terminal

[poetaman]

Line endings for macOS/Unix terminals: A 29-row ansi art has only 6-rows on macOS terminal

[andyherbert]

I committed a (possible) fix in the repo some time ago, but didn't build a new release that wrote implied line endings (line feed only) when exporting at utf-8, because I presume this is what most people expect.

a03ed76

[bart-d]

a terminal width of 80 columns is assumed unless specified otherwise (SAUCE). if you want to display on wider terminals, you need to parse the escape codes and wrap the lines yourself. This is not a Moebius specific item, most if not all editors assumes a terminal width of 80.

[poetaman]

Steps I used to convert for utf-8 format:

cat LU-Holiday.ans  | iconv -f CP437 | sed 'H;$!d;x;s/\x1A.*$//'

[poetaman]

Check my first hand-edited version is now available for modern terminal emulators (colors depend on terminal colors):

poetaman/arttime@153cd08#commitcomment-88263554

An ideal and concise spec for outputting ANSI for modern terminal emulators would be:

1. break every line at art width,
2. start and end every line with with clear escape code \E[0,
3. patch places where author assumes default black background and default white foreground within art so it picks terminal's black/white instead of terminal's background/foreground (can require a combination of: a) replacing \E[49m with \E[40m, b) \E[39m with \E[30m, c) adding/adjusting spaces at edges).

Am not suggesting Moebius to not do what it does today, additionally implementing an export option that follows the spec above will make it easy to use ANSI art in modern terminal emulator based applications. Terminal emulators are the most natural home for ANSI.

[poetaman]

@andyherbert Nice, I would totally give it a try after your upcoming build is released. Btw, request 2) start and end every line with with clear escape code \E[0 from above comment would be ideal to have. Here's my reasoning why 1) might not be sufficient for modern terminal emulators. Am copying my comment here from the same issue filed on pablodraw (cwensley/pablodraw#70 (comment)):

@tracker1 Sooner or later users will also hit the issue where they cat the file on a wide terminal (wider than art) and the area to the right of art has stripes of different colors than the terminals background. Given modern terminals can be arbitrary size, and user might want to place the content anywhere on the screen, it would be good if styling of art does not interfere with contents around it. One could argue that every application that wants to display ANSI art in modern terminals should parse escape sequences in prior line, save it, clear it at boundary, and recreate it at the beginning of next line. It would be difficult to say the least, and error prone. I would assume such state information already exists in some form in pablodraw as its renderer is able to render every glyph accurately with desired style. Here's the suggestion from my above post (copied here):

An ideal and concise spec for outputting ANSI for modern terminal emulators would be:

1. break every line at art width,
2. start and end every line with with clear escape code \E[0,
3. patch places where author assumes default black background and default white foreground within art so it picks terminal's black/white instead of terminal's background/foreground (can require a combination of: a) replacing \E[49m with \E[40m, b) \E[39m with \E[30m, c) adding/adjusting spaces at edges).

Think of it as placing an image in modern day UI, the stylizing of the image and its caption shouldn't affect the style of the contents around it (hence the trailing \E[0). Same goes the other way round, an application's line styling shouldn't affect the image being placed (hence the beginning \E[0). Whoever is coding their application and placing such a text-element on a wide terminal, they are responsible to recreate the styling they want after the trailing \E[0 that marks end of art (i.e for the region of their application). IMHO it will make developing for modern terminal's UI easier if such pattern is followed in general.

P.S. I may be slow to respond in coming days.