Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Durdraw – a modern ANSI art editor for modern Unix terminals (github.com/cmang)
154 points by indyjoenz 9 months ago | hide | past | favorite | 29 comments
I've been working on an ANSI art editor off and on for a while. It works like a traditional ANSI text editor, except it supports 256 colors, Unicode and CP437 encoding, frame-based animation, custom UI themes, terminal mouse input, HTML and IRC color output, and runs in Utf-8 terminals.

It's written in Python and curses, and is fairly portable across Unix systems. If you have ever used TheDraw or Aciddraw, the user interface is similar. It can also load/convert, view, edit and save most CP437 (MS-DOS style) ANSI art in a Utf-8 terminal, so you can view ANSI artscene packs in the comfort of your favorite terminal, and even convert them into 256 color Unicode ANSI.

I've been using it for my own ANSI and ASCII art for a number of years, and hope this will help artists work with less restrictions. I think there is a lot of opportunity for ANSI art beyond its dominant 16-color Code Page 437 format. We all have computers with amazing ANSI terminals with modern features. Shouldn't they be the natural home for making text art?

It's still a work in progress, and I'm always adding features. Thanks for checking it out!




I've been waiting for something like this. Is animation supported? Any plans for Android support?


Thanks! Yes, animation was one of the earliest features. It uses its own animation engine and file format (which is a gzipped JSON file), which gives the artist fine control over the timing (unlike traditional ansimation files), by giving them frames-per-second speed control and custom delays on frames. There is a video or two on youtube demonstrating this, and you can scroll down on the Durdraw homepage and readme to see examples.

I have given some thought to Android and iOS versions, and would like to make it happen, but it isn't a high priority at the moment. That is interesting that you might be interested in an Android version. Maybe sometime this year.

Edit: Just to be clear, animation does not require any programming or coding. You simply create frames, draw, switch between them, copy and edit frames, etc, like a traditional animation studio.


This is awesome. Since Steamboat willy is officially in the public domain as of today.....

So, it installs in windows powershell https://i.imgur.com/1Yt1V5v.png - but attempting to run it just pops up with "what program do you want to open this with" - I tried it in powershell, Anaconda Python CMD, regular CMD/run as admin - all the same result.

How troubleshoot?

Could I run it in a docker more easily?

Running this on an android table might be fun - but the menu UX might need to be more ribbon-style?

EDIT:

I just threw up a ubuntu VM and installed it there: https://i.imgur.com/nbtmXwN.png

SWEET


I'm glad you got it working. I'll probably work on a Docker installer in the future.

Normally, in Windows, the best way to run it in WSL. There is an issue with windows-curses that durdraw doesn't like, and keeps it from running natively in Windows (in powershell, etc) without WSL.

Yes, a tablet or phone version would need to be re-designed to be touch friendly, naturally.

Thanks for checking it out. :)


I have WSL installed, I gues I dont know how to invoke durdraw with WSL.

Question - can you change the canvas size/draw area? I'd like that to be in the INI default config as an option?

I want to have my terminal transparent for tracing an image in the background, but the draw area is in the top left and small, can the draw area be centered in window and configurable in size? or is the limitation of actually it being an in terminal app?

https://i.imgur.com/vdf8fEv.png

--

Edit - I found it, but setting -W and -H dont work, so I just changed the settings in the .py

EDIT: It was -m for the win.

I doubled the default, will it have issues?


There are currently 3 ways to set the canvas size.

1: Use the command line options -W and -H or --width and --height to set the numbers of columns and lines. run "durdraw --help" for more command-line options.

2: Check the help screen and scroll down to the "Canvas Size" section. There are keys for increasing and decreasing the canvas size.

3: You can also use the -m or --max command-line option to start the canvas size at the maximum size for your terminal window.

I will continue to work on the canvas size stuff an making it easier to customize.

I like your idea of optionally centering the canvas in the screen. Thanks for the suggestion. I might do that in a future version. (Same with the .ini file.)

You might also consider increasing your terminal font size so the canvas is not so small, and moving it around to line up with the image in the back.

I'd have to revisit it to make sure it still works well, but it tries to support a transparent terminal by default, with the --blackbg option to force a black background in the canvas.

Edit: Canvas resize keys are: esc-" insert line esc-: delete line esc-> insert column esc-< delete column


Oh, for WSL... You would use something like Windows terminal, and start an Ubuntu (WSL) terminal session from there. It will act similar to a Linux VM terminal, and you can download, install and run Durdraw from there.


Ill try all these! Thanks

Im an idiot, I couldnt launch WSL with my ubuntu vm running. No resources. Ill try that without VMs


I'll look into -W and -H. It's probably a bug. Thanks for letting me know.

I am not sure what you mean by "doubled the default" exactly.


in the main.py i changes 80 to 160 and 24 - 1 to 49 -1

but it was the -m I was looking for. -H -W didnt work on the command line, It looked like you had it set to 80 if -W was -H was >80 it sets it to 80?


I originally started working on Durdraw because I was trying to animate some ASCII art with Pablodraw and Photoshop, and found it incredibly tedious. I ended up making my own editor for any future animations.


I wonder how much of the ANSI spec we can use and still call it ANSI art. There are many sequences that were not supported by ANSI.SYS that are part of the standard, some of which are supported by modern terminals. Sadly, Tektronix graphics and ReGIS never made to the spec. Tools like `htop` and `glances` would look a lot more awesome with that.


I think the limitations of ansi.sys became the standard because it's the implementation that everyone had access to and could reference, not because it is the exact full set-in-stone canonical specification laid down by the ANSI standards committee overlords.

I think something similar applies today. Most people are using xterms or terminals that implement a large, fairly standard set of xterm and ansi escape codes (including things like Xterm 256 color, Mouse reporting, maybe RGB colors, Unicode). So that's what "modern" ANSI art can and maybe should target. At least raise the standard for terminal art beyond the 1980s IBM-PC to modern, widely implemented standards.

Then there is the problem of there being hundreds of ANSI editors and viewers that expect 16 color Code Page 437 art. Moebius (the ANSI editor) sidesteps this problem by using .utf8.ans to imply a Utf-8 ANSI, which also implies Xterm compatible escape codes (like 256 color). Right now Durdraw does not implement any file suggestions for saving, but in the future I might do that.


Chapter 4 - http://bitsavers.org/pdf/dec/terminal/gigi/EK-VK100-TM-001_V...

VK100 (aka GIGI) lets you do ReGIS graphics and optionally download BASIC programs to run on the client. It implements VT52 (ANSI) by default, but you could easily extend it to support full VT102 or VT400 codes too.


This looks like an interesting rabbit hole. I have heard of ReGIS graphics but am not familiar with the standard implementations or the VK100 terminal. Is it widely supported?

Thanks for the heads up and interesting manual, vaxman! This might lead to some interesting possibilities/magic for a future version, or alternative drawing program.


I'll try it sometime. love feature set. I have a game using a homebrew curses-based engine too so Durdraw might be useful in my workflow

If I dont use someone elses tool I'd likely end up making my own anyway haha so saved LOE is always good.


Very interesting! Does it have a function to convert images to ascii art?


It doesn't. Thanks for the great question. However, I made another program a while back that plays GIFs and images in a text terminal similar to what you're describing (see https://github.com/cmang/gifterm), and I plan to incorporate that functionality into a future version of Durdraw.


I've come across jp2a in the past for converting jpeg-to-ascii:

https://github.com/cslarsen/jp2a

and there is also this image and video-to-ascii tool in case it might be of use:

https://gist.github.com/motiondesignstudio/9374326


Looks really great! I wanted to write something like this but never got around to it.


Thank you! Feel free to contribute patches, feedback, etc. :)


https://github.com/mkrueger/icy_draw


Icy Draw is a very good newschool ANSI editor, too. The developer is very skilled and he put together a great, feature rich tool in a short amount of time.

I'd love to steal some of the features from it. Icy Draw joins the many GUI ANSI editors, though (like Moebius and Pablodraw), and Durdraw tries to get away from that by operating using real escape codes and real terminals. We also seem to have a different philosophy on animation.


TheDraw was one of the few pieces of 1990s shareware i purchased, and i have fond memories of it, but i feel compelled to ask: what use is that sort of thing nowadays? Back then we used them to make animations for dial-up BBSes, but the internet has long since obsoleted that. :-?


Thanks for taking a look. There are a few uses for a program like this in 2024.

1: Some people still make ANSI and ASCII art as a means of exploring the medium.. well, artistically. Check out https://16colo.rs/ and you will see what I mean. They showed around 30 ANSI art packs published for the year 2023. It isn't exactly the heyday of the 90s, but it's not completely dead, either.

2: Some people like to use ASCII art in text user interface programs, in README files, etc. This is probably the real modern use for a program like this.

3: BBSs aren't completely dead, either. :) See: https://www.telnetbbsguide.com/ for examples. Most of them cater to the old IBM-PC style character encoding (or some other antiquated platform) and ANSI standards, but I think there is opportunity to have modern 256 color Unicode BBSs. With social media being so problematic in 2024, why not enjoy a tried and true medium? They usually connect over the internet now, of course.

I admit, the commercial applications are limited. It's mostly just good creative or nostalgic fun.


> It's mostly just good creative fun.

The absolute best justification for coding. Thank you for your detailed response.


Don't discount #2 there. I still make ASCII art when commenting source code. Flow charts! I like to keep documentation as human-readable and editable text. (Version control friendly.)

ASCII art diagrams can be automatically rendered to an image, too: https://casual-effects.com/markdeep/


After a long-time collaborator got bit by the ansi/ascii art bug we slapped together a silly little game during the covid lockdowns using his ANSIs for sprites:

https://sars.pengaru.com/

experimental outdated wasm build @

https://sars.pengaru.com/wasm/

I found it kind of interesting as a medium for quick-n-dirty cheeseball horrid pixel style art. There's something to be said for a legible toilet paper roll in so few glyphs worth of creative effort/time.


I used Moebius a few months ago for a new corporate logo that couldn't be drawn in plain ASCII.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: