macos terminal.app issues with extended ansi
eyooooo opened this issue · comments
ive been struggling to get the extended ansi chars to work on a 2021 mbp terminal.app. ive tweaked all the dials and buttons in the profile but no luck yet. hoping someone else maybe has a tip?
thanks
EDIT:
I did not realize you were using the -A parameter for Code Page 437 characters. Confirmed, this is a problem in newer versions of macOS. Unless I'm mistaken, it looks like macOS's "Western (ASCII)" encoding mode no longer decodes Code Page 437 characters correctly. (It used to work in Mac OS X.) It would be nice to find a way to draw IBM-PC ANSI in macOS terminals again. Marked as a "Bug" for now.
Original post (assuming the user wanted Unicode characters):
Hmm. I'm having trouble reproducing this issue in macOS terminal.app. Please check the following..
1: Make sure your terminal's "Text Encoding" is set to "Unicode (UTF-8)." It should be in the "Advanced" tab of your Terminal.app Profile settings.
2: Set your TERM environment variable to xterm-256color
3: Make sure you aren't passing -A or --ansi to the command-line of durdraw, unless you know that's what you want (it changes the character encoding to be compatible with old DOS and Win9x PCs, aka Code Page 473 instead of Unicode)
4: Have you tried a different font? I am using Monaco in Terminal over here.
5: Does pressing CTRL-L (force redraw) clean up the screen?
Thanks, eyooooo
Note that if you DO want to use IBM-PC ANSI style extended characters (the -A option), like the old school ANSI art packs, you will need to change the character encoding to "Western (ISO Latin 1)" and use a different font (like the dos437.ttf bundled with Durdraw) that supports that character encoding.
Hmm. I'm having trouble reproducing this issue in macOS terminal.app. Please check the following..
1: Make sure your terminal's "Text Encoding" is set to "Unicode (UTF-8)." It should be in the "Advanced" tab of your Terminal.app Profile settings. 2: Set your TERM environment variable to xterm-256color 3: Make sure you aren't passing -A or --ansi to the command-line of durdraw, unless you know that's what you want (it changes the character encoding to be compatible with old DOS and Win9x PCs, aka Code Page 473 instead of Unicode) 4: Have you tried a different font? I am using Monaco in Terminal over here. 5: Does pressing CTRL-L (force redraw) clean up the screen?
Thanks, eyooooo
Fixed! In the readme its suggested to use Western ASCII text encoding when passing -A. I switched back to utf8 and it looks correct... running this like durdraw -A --256color
also interesting note... switching to xterm-256color actually removes the color bar on the bottom while using plain xterm terminal the color bar shows.
edit: hmmm weird. xterm-256color i can select a lot more fg colors but no bg colors. i think regular xterm is 16 colors which is why they are displayed across the bottom?
I'm glad you got it working! Unfortunately the version of Ncurses that ships with macOS is still quite ancient, and has trouble with 256-color mode, which is why you are seeing 16 color mode instead. Durdraw falls back to 16 color when 256 color mode fails. I'm not sure why it's disappearing like that for you - have you tried stretching the window out a little bit?
Upgrading to a newer Python and Ncurses build should fix it. Unfortunately Apple doesn't make that super easy, and I'm hoping a macOS update addresses this soon..
edit: hmmm weird. xterm-256color i can select a lot more fg colors but no bg colors. i think regular xterm is 16 colors which is why they are displayed across the bottom?
That is correct. Background colors don't work yet in 256 color mode. I haven't quite figured out what's keeping it from working yet, but it's on the agenda. Edit: Part of the problem is that the Ncurses 5 ABI, which macOS uses by default, has a limited number of color pairs. Ncurses 6 ABI addresses this. But I haven't sorted out getting it working with Ncurses 6 yet.
Hopefully you should be able to just click on the FG color at the bottom, in 256 color mode, and see the palette of all the colors. Or press esc-c to bring up that color menu. Then use the arrow keys or mouse to select a color.
Note that if you DO want to use IBM-PC ANSI style extended characters (the -A option), like the old school ANSI art packs, you will need to change the character encoding to "Western (ISO Latin 1)" and use a different font (like the dos437.ttf bundled with Durdraw) that supports that character encoding.
weirdly - it seems that utf8 encoding gives the best result with the dos437 font. using western ascii or iso latin 1 results in being unable to see the color menu for me.
also caught your edit while writing this comment. got it on the bg color situation.
sorry for being a PITA here. other than the occasional crash, your recommended settings above but utf8 encoding looks like its working.
update: the color menu does display using western latin iso 1 but its invisible until i scroll through the colors
@cmang if all of this is old news feel free to nuke this issue. only thing weird i see here is utf8 encoding seems to look more correct than western ascii or latin iso.
im on a 2021 14" mbp m1 running ventura 13.1
sorry for being a PITA here. other than the occasional crash, your recommended settings above but utf8 encoding looks like its working.
No worries. It's great to get some feedback users. :) It looks like Code Page 437 is struggling in Durdraw on the Mac. I'll be honest, I draw in Unicode 256 color mode 90% of the time nowadays. The Code Page 437 instructions are long in the tooth.
I'm having the same symptoms as your first post trying to get IBM-PC ANSI blocks working. It looks like maybe macOS did something that changed their Western (ASCII) encoding, in a way that breaks these Code Page 437 characters. :/ I can't get it working in iTerm, either. macOS Ventura 13.2.1 here.
I'll put any updates on this issue into this thread.
sorry for being a PITA here. other than the occasional crash, your recommended settings above but utf8 encoding looks like its working.
No worries. It's great to get some feedback users. :) It looks like Code Page 437 is struggling in Durdraw on the Mac. I'll be honest, I draw in Unicode 256 color mode 90% of the time nowadays. The Code Page 437 instructions are long in the tooth.
I'm having the same symptoms as your first post trying to get IBM-PC ANSI blocks working. It looks like maybe macOS did something that changed their Western (ASCII) encoding, in a way that breaks these Code Page 437 characters. :/ I can't get it working in iTerm, either.
I'll put any updates on this issue into this thread.
ive tried to get into creating ascii art for 15y - i tend to get hungup on the setup and then fizzle out. i apologize for wrapping u up in my excitement ;) im sure folks with more experience are much less drama.
thanks again for all your work.
ive tried to get into creating ascii art for 15y - i tend to get hungup on the setup and then fizzle out.
If that's the case, you might consider drawing using UTF-8 mode instead of trying to properly emulate an IBM-PC terminal, if you want block drawing characters.
I know the IBM-PC ANSI scene is still using CP437 encoding (for good reason), but when it comes to text modes in 2023, Unicode is better supported than CP437 ever was. In my opinion it's very nice to use and edit this ANSI art directly in the terminal, which is one of Durdraw's advantages, and it's getting harder and harder to find terminals that speak CP437. Unicode is also the default and most tested mode of Durdraw, and the least likely to have issues.
Dos437.ttf (or a similar "VGA" font) using Utf-8 blocks is probably good compromise if you want that old school feel in the terminal. But, I think you will need to fix the character encoding in your terminal if you want your exported ANSIs to show up right in PC ANSI editing and viewing software (Pablodraw, etc).
also interesting note... switching to xterm-256color actually removes the color bar on the bottom while using plain xterm terminal the color bar shows.
I believe this is an issue with the Dos437 font. It would be nice if Durdraw showed the colors in a way that worked right in every font, wouldn't it? :) I didn't know this was a problem, thanks for bringing it to my attention.
ive tried to get into creating ascii art for 15y - i tend to get hungup on the setup and then fizzle out.
If that's the case, you might consider drawing using UTF-8 mode instead of trying to properly emulate an IBM-PC terminal, if you want block drawing characters.
I know the IBM-PC ANSI scene is still using CP437 encoding (for good reason), but when it comes to text modes in 2023, Unicode is better supported than CP437 ever was. In my opinion it's very nice to use and edit this ANSI art directly in the terminal, which is one of Durdraw's advantages, and it's getting harder and harder to find terminals that speak CP437. Unicode is also the default and most tested mode of Durdraw, and the least likely to have issues.
Dos437.ttf (or a similar "VGA" font) using Utf-8 blocks is probably good compromise if you want that old school feel in the terminal. But, I think you will need to fix the character encoding in your terminal if you want your exported ANSIs to show up right in PC ANSI editing and viewing software (Pablodraw, etc).
just cant seem to get 100% success with non utf8 - xterm with western iso latin1 is basically perfect but the colors dont display. prob better to deal with the color display than worry about export issues?
I fixed some bugs that were making 16 color mode crash, and I'm fixing the --ansi (cp437) mode color picker. I should have an update for you tonight.
Ok. I just pushed out version 0.18.2. It has the fixes for the Code Page 437 color picker, and some 16 color mode bug fixes. 256 color mode should work right with Code Page 437 mode now, too. (Though, still no background colors...)
Can you please check it out and see if it fixes the issues for you? Does the color picker work now, and are you still getting any crashes?
Here is what it's looking like for me, and my terminal (iTerm) settings:
Note that those colors are not the most amazing approximation of CGA or VGA textmode. I'm not sure there's much I can do about that, short of making a GUI to simulate different computer video modes and fonts. But as an end user, you can customize your terminal font colors to look more like CGA/EGA/VGA colors.
And for those screenshots, both of which are using Code Page 437 characters, I was using:
durdraw --ansi --16color
and for 256 color:
durdraw --ansi
or:
durdraw --ansi --256color
The important terminal settings are:
- Character Encoding: Western (ISO Latin 1)
- Font: dos437
- Enable Mouse Reporting
- Report mouse clicks & drags
I also think enabling "Blinking Cursor" helps.
Edit: hopefully you can draw your IBM-PC ANSI art in your Mac terminal now :)
hmmm your terminal preferences window looks different from mine.... maybe i am missing some adv setting?
i am away from my mac for the next few hours - will report back.
edit: ah you are using iterm... maybe i will try switching from terminal.app
ah you are using iterm... maybe i will try switching from terminal.app
I would consider it for now. I enabled the same settings in Terminal.app and it does seem to work, but the mouse is far less responsive.
just tested latest push in iterm2 and terminal.app - both work!
thanks for everything.
Awesome. Thank you for helping me track down these bugs!
I'll go ahead and close this as fixed.