Create terminal-friendly ANSI art directory, so art can be imported in applications like arttime

[poetaman]

I recently have been working on a FOSS application that brings text art to terminal emulators of developers. It's a clock and multi-tasking time manager that also displays text art. The project also aims at curating quality text art. Though its ≈450-strong collection lacks much ANSI as ANSI seems to use older format and not be much terminal-friendly.

I checked some of the ANSI art in your repository, it might fit well there, though not all of it (some are just too big to fit on a terminal screen). Here's a summary of problems that we will have to deal with:

• Art is encoded in old CP437 format, convert it to UTF-8.
• Another issue is that ANSI can have special metadata called SAUCE record, that will have to be dealt with too.
• Filter ANSI art by size.
• Filter SFW from NSFW ANSI art. arttime and other users might just want SFW ANSI art.

Here are some arttime's links: 1) Homepage: https://github.com/poetaman/arttime 2) Screenshots: https://github.com/poetaman/arttime#screenshots 3) Installation: https://github.com/poetaman/arttime#installation 4) Release notes for latest version (1.9.2): https://github.com/poetaman/arttime/releases/tag/v1.9.2

Here's an example of how ANSI art would be put to use in the clock/timer:

[poetaman]

+@xero as he seems to have done some work to similar effect. The above taco art is from his gists.

[xero]

there's a lot more @ https://git.io/food i went through a weird phase with terminal based food

some of the stuff i made by hand. some of the stuff i draw in mobius or pablo then convert from CP437 to unicode with a little c program https://pastebin.com/Pp1W4PfG

[tracker1]

Note: cp437 -> utf8 can probably be done with just luit utility pretty easily. Another good idea would be converting the basic 16-color codes to true colors that match the CGA colors, since most terminals will show them wrong by default... Have thought about using a similar filter as luit for this myself.

[poetaman]

@xero Ah thanks! Am new to ANSI. Do you know if that program takes care of SAUCE record? I mean does it convert any/all ANSI or will it require further processing? I have tried using iconv on some of the ANSI art in this directory to convert to UTF-8, the result looks not that great...

[tracker1]

@poetaman may have to manually strip and re-add the sauce after conversion, or just strip/read before conversion to display... not sure what the app/intention really is...

[poetaman]

@tracker1 Not sure what you meant by "not sure what the app/intention really is...". If the question is about arttime, its a stylish terminal-based timer/clock that displays text art or flip-flopping text art animation.

[tracker1]

Okay, so the desired output, is a conversion of the .ans/.bin/.ice files to be more terminal friendly in a modern terminal? That being the case, as I mentioned, would need to strip the sauce, lconv the characters for utf8, then optionally re-add the sauce... would also likely want/need to convert the basic vtx/ansi color codes to rgb codes so that the right colors are used. Creating a script to process a single file would be relatively trivial... actually converting the entire archive, that would take more time and effort.

[poetaman]

@tracker1 Yep that is the intention, to have a collection that renders best on terminals. That would be wonderful, other terminal-based applications would also benefit from the treasure trove of text art in ANSI.

[sairuk]

imo this archive should aim preserve the original art as close to release as has been possible to find.

if you want to put together a curated list that's cool, but i'd suggest it should be run separately from the main archive with tooling to identify and convert art for use with your tool if necessary.

[lordscarlet]

It didn't click until I read @sairuk's reply what you might be asking for. They are absolutely correct, the files in this repository will absolutely not be converted to utf-8. I'd that is your goal, you should handle that in the tooling on your side or pre process everything.

If all you want is help in creating your tooling, that is all well and good.

[poetaman]

@lordscarlet Someone has to store Unix-friendly ANSI art somewhere. The first priority is tooling, and translation. Whether the owners of this repository want to host Unix-friendly ANSI art is their choice.

[poetaman]

@xero For some reason this does not render well using the steps known so far. I even removed SAUCE metadata using Moebius, and converted it to UTF-8, but it doesn't work. Perhaps this could be one of the test files, given it looks like a good piece of work.

Link: https://github.com/blocktronics/artpacks/blob/master/Blockfury/LU-Holiday.ans

Png:

+ @PhMajerus given he seems to be working on similar goal.

[lordscarlet]

@lordscarlet Someone has to store Unix-friendly ANSI art somewhere. The first priority is tooling, and translation. Whether the owners of this repository want to host Unix-friendly ANSI art is their choice.

@poetaman I am the owner of this archive.

I'm not sure why you think someone "has to" do this. Someone like yourself can choose to do it, but there is no reason it has to be. I also have no problem with someone doing it, but this isn't the place to store it. The intention of this archive is solely to store packs as they were originally created (with some exception such as removing known viruses)

[lordscarlet]

I don't mean to come off as a jerk, and I am afraid I have. I am happy that someone wants to use the artwork. If converting to utf-8 is what makes the most sense for your purposes, I think a lot of people here could help. If you need somewhere to store it, I am happy to help figure out a good place for it.

[xero]

@xero For some reason this does not render well using the steps known so far.

trying to render a gorgeous Luciano piece is a very noble cause. but I made my janky script just to help render my own art into the terminal. there's a lot of different ansi art editors that have been created throughout the years, lots of artists using different tooling. this archive preserves them in their pure original forms. I think it's cool that you want to make this program to showcase text art. not sure asking for help. converting this entire archive will be a process. anyone is willing to undertake. Plus there's some crazy stuff from the '90s when Lord jazz for instance was in his Marilyn Manson phase, you might not want ✌️🤣

if you want to take individual pieces and convert them on a case-by-case basis, i think that will be your best route. you really should check out https://16colo.rs if you've not yet and just get lost in all that amazing art.

[poetaman]

@xero Seems like a line wrapping issue. Check the tickets I filed: https://github.com/blocktronics/moebius/issues/215, https://github.com/cwensley/pablodraw/issues/70

[poetaman]

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

https://github.com/poetaman/arttime/commit/25336eedf90066abef4fac94b7acea5bcd74c157#commitcomment-88318249

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).

Command:

arttime --nolearn -a holiday -t "Real hackers don't code on beach"

Following is a docker command to give this art a try in unix terminal of your choice. Colors depend on terminal emulator's theme. Same command also works for podman, just replace the name 'docker' with 'podman'.

docker run -e TERM -e LC_ALL=C.UTF-8 -e TZ -it --rm zshusers/zsh:5.8 zsh -c '
  export SHELL=$(command -v zsh)
  apt update
  apt install -y curl less procps
  curl -fsSL https://gist.githubusercontent.com/poetaman/bdc598ee607e9767fe33da50e993c650/raw/d3d5e29427304d977044b594fbb6cc84616c30d4/arttime_online_installer.sh | TERM=xterm-256color zsh
  TERM=xterm-256color ~/.local/bin/arttime --nolearn -a holiday -t "Welcome to the world of ASCII/ANSI, press \"h\" to toggle help/art.";'

[bart-d]

You have to be aware that the artwork present in a public archive remains the intellectual property of their creators. Under no circumstances this means the artwork is free to be reused and/or transformed into another format. Most artists that created artwork specifically in CP437 and for a specific terminal are very concerned about how their work is displayed (and a few of them are named in this thread already). Converting CP437 to UTF-8 will always incur changes to as to how the work is displayed as the work was mostly intended to be shown on CRT monitors which were using rectangular pixels and introduced letter spacing directly in the graphics adapter. A straight conversion to UTF-8 will not be able to maintain the aspect ratio of the output. In addition to that, the colors are also very specific, your most recent output changed this too, the creator might just not want to have his work reproduced in this way.

This doesn't mean your project is in vain, you just have to respect intellectual property. It would be best to either seek approval from the individual artists which work you want to reproduce/transform or to have artwork specifically created for this purpose, which would also solve your specific dimension requirements.

Sixteen Color is a historic archive of artpacks that were made for the PC MS-DOS ANSI.SYS driver specifically, it wouldn't really serve the purpose an archive to transform the contents into something that it's not trying to document at all. You're coming from a different angle here and I understand that it's not exactly suited for what you want to do. So I'm just trying to explain how strange your question may come across. But once again, seek cooperation and/or approval from artists directly will serve your goals better as opposed to trying to "convert" a historical archive.

[matthewpkemp]

I would note that removing sauce is akin to taking the signature off of a physical painting. Sometimes artists sign their art inside the image itself(which attribution should remain in any rendering), and others used sauce for some pieces in lieu of this signature on the piece itself.

Don't forget many of the packs claim rights and technically, while not enforced in many practices, could be enforced. Utilizing pieces without permission, even in an open sourced application, without permission could constitute a violation of intellectual property laws.

[sairuk]

You should be doing a runtime conversion in memory (or a temp file, if anything) and manage the 80c/SAUCE requirement (line wrap) yourself processing the escape codes, not converting pieces to store in a repo. The original piece should stay intact.

Not all terminals are going to be able to display the piece as per the artists original intent and that needs to respected. I am assuming you had permission from the artists to edit that work and commit it to your repo, if not you should be sourcing perms.

I ran into most of these display issues already with pyans (+others colours, cols, codes, etc) which are not for upstream to correct/manage in historical archives such as this.

[hpjansson]

This copyright assertion raises an interesting issue. I've the impression that the scene isn't really sticklers for paperwork -- what are the actual license terms for the artworks archived and distributed by sixteencolors?

[matthewpkemp]

@hpjansson You may want to read the wewill.sue file in every ACID release. I would say I am more than happy if my work is distributed as is, or displayed in personal usage situations. If it's being distributed in other ways, or as part of a package that makes no attribution, I would take umbrage at this usage if I haven't given permission for this. Artists are used to the packs being distributed on BBSes and website in various formats for personal usage and viewing.

[hpjansson]

Thanks. The ACID terms are a great clarification, and I suppose it also reflects the thinking among the other rights holders -- "share, but don't exploit, and don't modify".

I was a BBS person back in the 80s and 90s, and must admit there were many of us who didn't think too deeply about it back then :-) But the risk of "outsider" commercial exploitation was basically non-existent too, and that's probably different today (e.g. a random Internet person could put artwork on t-shirts and other merch and somehow make it big, and it makes sense that you'd want to avoid that).

The ANSI "fidelity" is not a new problem (I remember viewing these in NComm on the Amiga, and its palette and the Topaz font gave them a different look) -- maybe a solution would be for 16c to bless a specific script or tool to JIT convert ans files to something that would make a good reproduction in modern terminal emulators? A bit like how Ansilove is used for PNG output currently.

[matthewpkemp]

@hpjansson I'm certainly not speaking for everyone, but I do believe as we've all grown since our childhood and we have a greater appreciation for creative works and their usage. It was my first PD boards back in the late 80s that started my interest in text mode graphics and here we are some 35+ years later talking about the rights of the artists. While I believe copyrights in the US have gotten out of hand, we should consider that most of these pieces do not fall into public domain yet. How Long does Copy Protection Last?. I think it's important to make sure artists sign-off before their artwork is used in any programs outside of distribution for personal usage (as with archives like sixteencolors). While I do not think the program here is trying to monetarily exploit the artwork, the developer should obtain permission or create their own artwork for such program like the one we are discussing.

[hpjansson]

Absolutely.

Maybe it's a digression, but I'm interested in the intersection between ANSI art and the command line, and got curious about the point made above that converting art to Unicode or displaying in a non-VGA environment (e.g. consoles with a different font/palette) may be against the wishes of the artists. Let's say someone set up a telnet or ssh-based BBS today and it had an artpack browser that rendered to Unicode -- people might feel different ways about that.

BBSes back then catered to a wide variety of platforms that rendered things differently, and today there are few people running VGA textmode, so PNG in a web browser has become the default. It would be cool if the link to terminals/command line were somehow preserved.

I don't think it's 16c's job to support this, though. Maybe it's separate worlds now, or I'm wrong and it always was. I'm grateful for the great conservation work you do.

[bart-d]

16c already supports this, every single item has a 'JSON' link where you can see the ansiflags as mentioned in SAUCE, but also the manual corrections that were made by editors regarding rendering. It also takes into account the default letter spacing and aspect ratio based on the time the artwork was created. While SAUCE is handy, there is an error margin to be taken into account. But also it was only created in 1994, work created before that date does not have metadata anyway and the most important flags related to rendering (such as fonts and aspect ratio) where only added to the spec in 2012. ansilove does not read SAUCE by default, it assumes the user knows what to do. But there is a non-default option to trust SAUCE whenever it's available. But taken the above into account, it's almost never the only item to be considered to get correct rendering of the items.