#dos2ansi β Public Fediverse posts
Live and recent posts from across the Fediverse tagged #dos2ansi, aggregated by home.social.
-
@dani Haha π
I'm running a (heavily configured) #fvwm3 here. This screenshot was just for demonstration that #dos2ansi and #showansi don't depend on any configuration, so this was a completely unconfigured X session in #Xephyr, which by default runs #twm.
You can even see the test mode in #xterm can only use 8 colors (because this is what the default xterm #terminfo entry announces), still the #xterm windows launched by #showansi have full color support, they explicitly set the terminal name to "xterm-256colors".
-
@dani Haha π
I'm running a (heavily configured) #fvwm3 here. This screenshot was just for demonstration that #dos2ansi and #showansi don't depend on any configuration, so this was a completely unconfigured X session in #Xephyr, which by default runs #twm.
You can even see the test mode in #xterm can only use 8 colors (because this is what the default xterm #terminfo entry announces), still the #xterm windows launched by #showansi have full color support, they explicitly set the terminal name to "xterm-256colors".
-
Not having added anything to #dos2ansi for a while now, I'd say v2.0 is the "final" version for now. I initially wanted that for v1.0, and it's amazing how many weird files, edge cases, and also ideas for improvements you can discover for something that "simple" π
I have ideas for future development, like provide the core functionalities as a shared library, like add some config file for dos2ansi itself as well (instead of just for #showansi), maybe even more ... but all of that can wait, it's IMHO "complete" as it is.
A #Debian package is attached to the release on github, and a #FreeBSD port is added ... anyone wants to help make it available in more repositories? π Would be most helpful if the fonts it uses by default are packaged as well and can be set as dependencies ...
https://repology.org/project/dos2ansi/versions -
Not having added anything to #dos2ansi for a while now, I'd say v2.0 is the "final" version for now. I initially wanted that for v1.0, and it's amazing how many weird files, edge cases, and also ideas for improvements you can discover for something that "simple" π
I have ideas for future development, like provide the core functionalities as a shared library, like add some config file for dos2ansi itself as well (instead of just for #showansi), maybe even more ... but all of that can wait, it's IMHO "complete" as it is.
A #Debian package is attached to the release on github, and a #FreeBSD port is added ... anyone wants to help make it available in more repositories? π Would be most helpful if the fonts it uses by default are packaged as well and can be set as dependencies ...
https://repology.org/project/dos2ansi/versions -
And now, the full docs for #dos2ansi v2.0 are available online as well:
https://zirias.github.io/dos2ansiIMHO manpages are an awesome documentation format. And with a little bit of "responsive" #CSS, they're well usable on a mobile as well -- I wished the typical "online man" sites would do something like that π
-
And now, the full docs for #dos2ansi v2.0 are available online as well:
https://zirias.github.io/dos2ansiIMHO manpages are an awesome documentation format. And with a little bit of "responsive" #CSS, they're well usable on a mobile as well -- I wished the typical "online man" sites would do something like that π
-
Released: #dos2ansi v2.0
https://github.com/Zirias/dos2ansi/releases/tag/v2.0The real "visible change" is documentation. #showansi now got a manpage as well, and the one for #dos2ansi improved a lot. Also better build instructions and some updates/corrections in the README. With these docs, you can hopefully make it do exactly what you want π
Also, the build system (my own homebrewn #GNU #make framework) got lots of improvements and fixes.
https://github.com/Zirias/zimk/ -
Released: #dos2ansi v2.0
https://github.com/Zirias/dos2ansi/releases/tag/v2.0The real "visible change" is documentation. #showansi now got a manpage as well, and the one for #dos2ansi improved a lot. Also better build instructions and some updates/corrections in the README. With these docs, you can hopefully make it do exactly what you want π
Also, the build system (my own homebrewn #GNU #make framework) got lots of improvements and fixes.
https://github.com/Zirias/zimk/ -
I'm planning to create a release #dos2ansi v2.0 soon, which will have more or less the feature set of v1.8, but with complete and helpful documentation for everything. Main work left to do for that is to add more text to the manpages π
At least, the tool I wrote for generating docs now has everything I'll need for that!
-
I'm planning to create a release #dos2ansi v2.0 soon, which will have more or less the feature set of v1.8, but with complete and helpful documentation for everything. Main work left to do for that is to add more text to the manpages π
At least, the tool I wrote for generating docs now has everything I'll need for that!
-
And now, my little documentation generation tool can also produce manpages in #HTML format (this will be useful for the #Windows version of #dos2ansi) π
Using simple/minimal semantic markup, the "manpage style" is entirely left to #CSS
Screenshots:
- Desktop unstyled
- Desktop bright mode
- Desktop dark mode
- Mobile dark mode -
And now, my little documentation generation tool can also produce manpages in #HTML format (this will be useful for the #Windows version of #dos2ansi) π
Using simple/minimal semantic markup, the "manpage style" is entirely left to #CSS
Screenshots:
- Desktop unstyled
- Desktop bright mode
- Desktop dark mode
- Mobile dark mode -
Now working on adding a manpage for #showansi as well. I noticed I need to add features to my "mkclidoc" tool in order to get something meaningful here ...
First step, added support for cross-references π -- next thing needed will be documenting related files...
Next #dos2ansi release will probably just be nice and complete documentation!
-
Now working on adding a manpage for #showansi as well. I noticed I need to add features to my "mkclidoc" tool in order to get something meaningful here ...
First step, added support for cross-references π -- next thing needed will be documenting related files...
Next #dos2ansi release will probably just be nice and complete documentation!
-
Here's a quick demo how the new documentation generation in #dos2ansi works π
https://github.com/Zirias/mkclidocScreenshots:
- Input format (on github)
- help (-h) output (on #Windows)
- manpage (on #FreeBSD)Might make sense to add some #HTML output as well, e.g. for the Windows binary package... π€
-
Here's a quick demo how the new documentation generation in #dos2ansi works π
https://github.com/Zirias/mkclidocScreenshots:
- Input format (on github)
- help (-h) output (on #Windows)
- manpage (on #FreeBSD)Might make sense to add some #HTML output as well, e.g. for the Windows binary package... π€
-
#dos2ansi v1.8 released!
https://github.com/Zirias/dos2ansi/releases/tag/v1.8There's some major rework inside adding support for seekable streams, which was necessary to implement the logic detecting #SAUCE even when the preceding DOS EOF character is missing.
Quite some improvements to the #showansi script as well, now comes with "fontsets" (explained in the comments in these and the config file) π
Plus added a manpage. Wanted a single source of truth (shared with the help output) and didn't find a good tool for that, so I quickly came up with my own:
https://github.com/Zirias/mkclidoc
It's bundled with dos2ansi now. Can produce man in both classic troff and BSD mandoc. The default choice is based on `uname` for now, tested on #FreeBSD and #Debian. -
#dos2ansi v1.8 released!
https://github.com/Zirias/dos2ansi/releases/tag/v1.8There's some major rework inside adding support for seekable streams, which was necessary to implement the logic detecting #SAUCE even when the preceding DOS EOF character is missing.
Quite some improvements to the #showansi script as well, now comes with "fontsets" (explained in the comments in these and the config file) π
Plus added a manpage. Wanted a single source of truth (shared with the help output) and didn't find a good tool for that, so I quickly came up with my own:
https://github.com/Zirias/mkclidoc
It's bundled with dos2ansi now. Can produce man in both classic troff and BSD mandoc. The default choice is based on `uname` for now, tested on #FreeBSD and #Debian. -
I just released #dos2ansi v1.7, which includes one final bugfix: Quoted output of #SAUCE metadata should use proper "shell-style" quoting, so it can be directly consumed by #showansi, which it does now. Plus #showansi got a (tiny) bit of optimization.
https://github.com/Zirias/dos2ansi/releases/tag/v1.7
Well, just after releasing, I found more stuff to tackle. No, not new bugs at least.
But more weirdly broken ANSIart files. Example:
https://16colo.rs/pack/root0297/FU-B%26B.ANSThis one *has* SAUCE metadata, but it's not properly "hidden" behind a DOS EOF character (0x1a), which means even 'type' on a real DOS machine will output the SAUCE gibberish below the pic π
So, there *might* be a v1.8 adding more heuristics to detect and parse more broken SAUCE ... π
-
I just released #dos2ansi v1.7, which includes one final bugfix: Quoted output of #SAUCE metadata should use proper "shell-style" quoting, so it can be directly consumed by #showansi, which it does now. Plus #showansi got a (tiny) bit of optimization.
https://github.com/Zirias/dos2ansi/releases/tag/v1.7
Well, just after releasing, I found more stuff to tackle. No, not new bugs at least.
But more weirdly broken ANSIart files. Example:
https://16colo.rs/pack/root0297/FU-B%26B.ANSThis one *has* SAUCE metadata, but it's not properly "hidden" behind a DOS EOF character (0x1a), which means even 'type' on a real DOS machine will output the SAUCE gibberish below the pic π
So, there *might* be a v1.8 adding more heuristics to detect and parse more broken SAUCE ... π
-
Yet another revision, #dos2ansi v1.6.3
https://github.com/Zirias/dos2ansi/releases/tag/v1.6.3--- brings yet another subtle bugfix in #showansi: To set the title with an escape sequence, it uses "printf %b" with its \-notation for control characters, so literal backslashes in the title must be escaped as well π
Apart from that, added nice "portability bikeshed":
- Removed the dependency on 'sed' again, quoting/escaping strings for 'eval' *can* be done in pure #POSIX #shell script.
- Added proper detection of the POSIX shell to my #zimk build system, along with variables to override the choice. Used that to generate the shebang for #dos2ansi. Really an awesome way to write /bin/sh without writing /bin/sh π (rumors say there *are* POSIX systems with the compliant shell in a different path ...)
Screenshot: Yet another file with "weird" title from #SAUCE
-
Yet another revision, #dos2ansi v1.6.3
https://github.com/Zirias/dos2ansi/releases/tag/v1.6.3--- brings yet another subtle bugfix in #showansi: To set the title with an escape sequence, it uses "printf %b" with its \-notation for control characters, so literal backslashes in the title must be escaped as well π
Apart from that, added nice "portability bikeshed":
- Removed the dependency on 'sed' again, quoting/escaping strings for 'eval' *can* be done in pure #POSIX #shell script.
- Added proper detection of the POSIX shell to my #zimk build system, along with variables to override the choice. Used that to generate the shebang for #dos2ansi. Really an awesome way to write /bin/sh without writing /bin/sh π (rumors say there *are* POSIX systems with the compliant shell in a different path ...)
Screenshot: Yet another file with "weird" title from #SAUCE
-
And now there's even #dos2ansi v1.6.2: https://github.com/Zirias/dos2ansi/releases/tag/v1.6.2
The good thing is: The issues I'm fixing here are getting more and more obscure π
First I noticed #xterm doesn't accept all #utf8 for its '-title' option, no matter what. But it *does* support the escape sequence to set a title, so, why not use this instead.
Having added support for that (and also optionally for setting the window size using an escape sequence), I had a look at quoting again. Indeed, #showansi failed for e.g. file names containing #shell special characters.
Therefore added a *safe* quote function. The downside is, it requires #sed now. Well ....
Screenshot shows both improvements, I picked a "maximum weird" file name and used a file that has an 'ΓΆ' in its title π₯³ -- in the showansi debugging output, you can see the quoting in action π€―
-
And now there's even #dos2ansi v1.6.2: https://github.com/Zirias/dos2ansi/releases/tag/v1.6.2
The good thing is: The issues I'm fixing here are getting more and more obscure π
First I noticed #xterm doesn't accept all #utf8 for its '-title' option, no matter what. But it *does* support the escape sequence to set a title, so, why not use this instead.
Having added support for that (and also optionally for setting the window size using an escape sequence), I had a look at quoting again. Indeed, #showansi failed for e.g. file names containing #shell special characters.
Therefore added a *safe* quote function. The downside is, it requires #sed now. Well ....
Screenshot shows both improvements, I picked a "maximum weird" file name and used a file that has an 'ΓΆ' in its title π₯³ -- in the showansi debugging output, you can see the quoting in action π€―
-
#dos2ansi v1.6.1 (a pure bugfix/service release):
https://github.com/Zirias/dos2ansi/releases/tag/v1.6.1* Fix possible crash (π) when querying for font or codepage on a file with a non-text #SAUCE type.
* Try to parse something meaningful even out of partially broken SAUCE dataYep, the possible crash was the reason to create a release even for a pretty "small" bugfix. π Chances are nobody would have noticed though, the SAUCE *display* was not affected, only the machine-readable query (-q).
Screenshot: The "offending" file. It even had literal ",1" written in the month field of the SAUCE date, but obviously meaning January here π
-
#dos2ansi v1.6.1 (a pure bugfix/service release):
https://github.com/Zirias/dos2ansi/releases/tag/v1.6.1* Fix possible crash (π) when querying for font or codepage on a file with a non-text #SAUCE type.
* Try to parse something meaningful even out of partially broken SAUCE dataYep, the possible crash was the reason to create a release even for a pretty "small" bugfix. π Chances are nobody would have noticed though, the SAUCE *display* was not affected, only the machine-readable query (-q).
Screenshot: The "offending" file. It even had literal ",1" written in the month field of the SAUCE date, but obviously meaning January here π
-
Meanwhile:
* Added a #Debian (amd64) package to #dos2ansi v1.6 release (on Github)
* Updated the #FreeBSD port here: https://people.freebsd.org/~zirias/patches/0001-converters-dos2ansi-Add-new-port.patch
* There's of course still the #Windows binary attached to the releaseMight push the FreeBSD port to official ports later ....
Screenshot: Random #showansi rendering ... π
-
Meanwhile:
* Added a #Debian (amd64) package to #dos2ansi v1.6 release (on Github)
* Updated the #FreeBSD port here: https://people.freebsd.org/~zirias/patches/0001-converters-dos2ansi-Add-new-port.patch
* There's of course still the #Windows binary attached to the releaseMight push the FreeBSD port to official ports later ....
Screenshot: Random #showansi rendering ... π
-
Just noticed the #showansi script from #dos2ansi is now "smarter" than the renderer on 16colo.rs π
When there's no (#SAUCE) metadata indicating the font to use, but the canvas after rendering turns out to be exactly 80x50 or 80x43, it just *guesses* that's most likely the VGA50 or EGA43 mode and picks that font π
(Of course, this "smartness" can be disabled with the "-S" flag)
Compare to this: https://16colo.rs/pack/avpack16/frg-ans2.ans
-
Just noticed the #showansi script from #dos2ansi is now "smarter" than the renderer on 16colo.rs π
When there's no (#SAUCE) metadata indicating the font to use, but the canvas after rendering turns out to be exactly 80x50 or 80x43, it just *guesses* that's most likely the VGA50 or EGA43 mode and picks that font π
(Of course, this "smartness" can be disabled with the "-S" flag)
Compare to this: https://16colo.rs/pack/avpack16/frg-ans2.ans
-
#dos2ansi v1.6:
https://github.com/Zirias/dos2ansi/releases/tag/v1.6* Fix cursor movement again, it never wraps or scrolls.
* Many smaller improvements to the #showansi script
* Add an example configuration using scalable fonts from https://int10h.org/oldschool-pc-fonts/ instead of the default bitmap fontsScalable fonts are a tradeoff here. You get freely configurable sizes and correction of aspect ratio. You lose pixel-perfect (perfectly sharp) display. You can't have both, unfortunately.
Screenshot shows scalable fonts π
-
#dos2ansi v1.6:
https://github.com/Zirias/dos2ansi/releases/tag/v1.6* Fix cursor movement again, it never wraps or scrolls.
* Many smaller improvements to the #showansi script
* Add an example configuration using scalable fonts from https://int10h.org/oldschool-pc-fonts/ instead of the default bitmap fontsScalable fonts are a tradeoff here. You get freely configurable sizes and correction of aspect ratio. You lose pixel-perfect (perfectly sharp) display. You can't have both, unfortunately.
Screenshot shows scalable fonts π
-
There was still room for improvement ....
From "just needs a little #script to turn #dos2ansi in a nice ANSIart viewer" to a ~400-lines "monster" in 8 days ... π
It *should* work well with any #POSIX #shell. I hope so. π
https://github.com/Zirias/dos2ansi/blob/master/src/bin/dos2ansi/showansi.in -
There was still room for improvement ....
From "just needs a little #script to turn #dos2ansi in a nice ANSIart viewer" to a ~400-lines "monster" in 8 days ... π
It *should* work well with any #POSIX #shell. I hope so. π
https://github.com/Zirias/dos2ansi/blob/master/src/bin/dos2ansi/showansi.in -
Found one of these old ones using lots of cursor movement foo that even mis-renders on
https://16colo.rs/pack/1991/SOUL.ANSGuess #dos2ansi is really implementing these correctly now π (finally!)
-
Found one of these old ones using lots of cursor movement foo that even mis-renders on
https://16colo.rs/pack/1991/SOUL.ANSGuess #dos2ansi is really implementing these correctly now π (finally!)
-
Playing around some more with some *very* old #ANSIart files ... blinking was obviously used more back then, and it's really nice #xterm can actually do that! π
(need to pass an extra -k flag to #dos2ansi here because there's no #SAUCE in this old file and the default is assuming bright colors instead)
-
Playing around some more with some *very* old #ANSIart files ... blinking was obviously used more back then, and it's really nice #xterm can actually do that! π
(need to pass an extra -k flag to #dos2ansi here because there's no #SAUCE in this old file and the default is assuming bright colors instead)
-
BTW, the color difference you see in these Windows screenshots is the classic "dark yellow vs brown" issue.
Quick background, with digital #RGBI signals (like used with #CGA), you couldn't have brown, but high-quality monitors (including IBM's own, but also a Commodore 1084 I have here) had extra circuitry adjusting dark yellow to brown by reducing the green component. With #CGA on a cheap monitor or a TV set, you still had "dark yellow".
#VGA finally moved to analog #RGB and used brown. Still many terminals today (including #Windows #Console) have dark yellow in their default palettes.
#dos2ansi must rely on the default palette when the terminal supports only 8 or 16 colors, but with a 256-color terminal, it uses "original" CGA/VGA colors. And of course, there's a switch to disable the "brown adjustment" π
Screenshot from #xterm on#FreeBSD showing both modes, actually this example looks like it might have been designed with "dark yellow" in mind.
-
BTW, the color difference you see in these Windows screenshots is the classic "dark yellow vs brown" issue.
Quick background, with digital #RGBI signals (like used with #CGA), you couldn't have brown, but high-quality monitors (including IBM's own, but also a Commodore 1084 I have here) had extra circuitry adjusting dark yellow to brown by reducing the green component. With #CGA on a cheap monitor or a TV set, you still had "dark yellow".
#VGA finally moved to analog #RGB and used brown. Still many terminals today (including #Windows #Console) have dark yellow in their default palettes.
#dos2ansi must rely on the default palette when the terminal supports only 8 or 16 colors, but with a 256-color terminal, it uses "original" CGA/VGA colors. And of course, there's a switch to disable the "brown adjustment" π
Screenshot from #xterm on#FreeBSD showing both modes, actually this example looks like it might have been designed with "dark yellow" in mind.
-
As hard to believe as it is, the #Windows #Console still supports #CP437. And with the "virtual terminal processing" introduced in #Win10, it also accepts escape sequences, obviously even the more obscure ones from ANSI.SYS π
So, on a somewhat recent #Windows, you can display most #ANSIart without any extra tool, 'chcp 437' and 'type' is enough.
#dos2ansi will still be helpful:
* The output is sanitized, using *only* SGR sequences and a #Unicode encoding (so, also suitable to store in a file)
* Correlated here, some "exotic" MS-DOS #codepages are supported.
* On Windows > win10, colors will be corrected to the CGA/VGA palette (first screenshot)
* It will still work if your terminal width is different from what the input file assumes (second screenshot)Screenshots show first 'type' with cp437 selected, then 'dos2ansi' π
-
As hard to believe as it is, the #Windows #Console still supports #CP437. And with the "virtual terminal processing" introduced in #Win10, it also accepts escape sequences, obviously even the more obscure ones from ANSI.SYS π
So, on a somewhat recent #Windows, you can display most #ANSIart without any extra tool, 'chcp 437' and 'type' is enough.
#dos2ansi will still be helpful:
* The output is sanitized, using *only* SGR sequences and a #Unicode encoding (so, also suitable to store in a file)
* Correlated here, some "exotic" MS-DOS #codepages are supported.
* On Windows > win10, colors will be corrected to the CGA/VGA palette (first screenshot)
* It will still work if your terminal width is different from what the input file assumes (second screenshot)Screenshots show first 'type' with cp437 selected, then 'dos2ansi' π
-
A few fixes were needed to #zimk (my very own #GNU #make framework) to make everything work perfectly again in #Windows #CMD.
Testing these now, here's building #dos2ansi on Windows with just 'make' and 'mingw' installed from #chocolatey π
(building worked before as well, but there were lots of glitches and issues like e.g. partially broken "clean" rules)
-
A few fixes were needed to #zimk (my very own #GNU #make framework) to make everything work perfectly again in #Windows #CMD.
Testing these now, here's building #dos2ansi on Windows with just 'make' and 'mingw' installed from #chocolatey π
(building worked before as well, but there were lots of glitches and issues like e.g. partially broken "clean" rules)
-
It's done, #dos2ansi v1.5 is here:
https://github.com/Zirias/dos2ansi/releases/tag/v1.5Apart from supporting all the cursor movement and screen erasing sequences that were needed for that silly file I found, there's now also support for the screen mode setting from ANSI.SYS (with non-text modes silently ignored).
There are also tons of little improvements to the "showansi" script, which should now work very well as a generic DOS ANSIart viewer picking reasonable defaults (and making it easy to override them if really necessary).
Example screenshot includes rendering this silly file again π
Have fun, and if you need some files to display, have a look at https://16colo.rs/
-
It's done, #dos2ansi v1.5 is here:
https://github.com/Zirias/dos2ansi/releases/tag/v1.5Apart from supporting all the cursor movement and screen erasing sequences that were needed for that silly file I found, there's now also support for the screen mode setting from ANSI.SYS (with non-text modes silently ignored).
There are also tons of little improvements to the "showansi" script, which should now work very well as a generic DOS ANSIart viewer picking reasonable defaults (and making it easy to override them if really necessary).
Example screenshot includes rendering this silly file again π
Have fun, and if you need some files to display, have a look at https://16colo.rs/
-
Oh freakin hell, of course this happens directly *after* release: I found some #ansiart file that really uses every obscure display-related feature of ANSI.SYS, and as a result, #dos2ansi v1.4 just renders garbage π
It now works with the latest commit, I had to implement:
- absolute cursor positioning
- cursor position saving and restoring
- all the erasing (line/screen) commands
- and additionally at least ignoring sequences to set the screen mode π€―Why is anyone doing that? First I thought save bandwidth for BBS, but this file has 7620 bytes, and processed with -AId flags (so only sequences used also available in ANSI.SYS), it shrinks down to 5906 bytes even using #UTF8... I really don't understand that π
Here's this file: https://16colo.rs/pack/arc-17/M0D-RMS1.ASC
#dos2ansi v1.5 will be there soon I guess...
-
Oh freakin hell, of course this happens directly *after* release: I found some #ansiart file that really uses every obscure display-related feature of ANSI.SYS, and as a result, #dos2ansi v1.4 just renders garbage π
It now works with the latest commit, I had to implement:
- absolute cursor positioning
- cursor position saving and restoring
- all the erasing (line/screen) commands
- and additionally at least ignoring sequences to set the screen mode π€―Why is anyone doing that? First I thought save bandwidth for BBS, but this file has 7620 bytes, and processed with -AId flags (so only sequences used also available in ANSI.SYS), it shrinks down to 5906 bytes even using #UTF8... I really don't understand that π
Here's this file: https://16colo.rs/pack/arc-17/M0D-RMS1.ASC
#dos2ansi v1.5 will be there soon I guess...
-
Time to verify all my additions to my #GNUmake framework #zimk didn't break compatibility with #Windows #CMD -- they didn't π
So, you can still build #dos2ansi yourself on Windows with the minimal set of tooling installed, e.g. using #chocolatey, 'choco install mingw' and 'choco install make' is enough βοΈ
The garbled output seen in the screenshot is a consequence of Windows #Console output being strictly unbuffered, which allows these things to happen with make jobs ... I see no way to work around this .... π
-
Time to verify all my additions to my #GNUmake framework #zimk didn't break compatibility with #Windows #CMD -- they didn't π
So, you can still build #dos2ansi yourself on Windows with the minimal set of tooling installed, e.g. using #chocolatey, 'choco install mingw' and 'choco install make' is enough βοΈ
The garbled output seen in the screenshot is a consequence of Windows #Console output being strictly unbuffered, which allows these things to happen with make jobs ... I see no way to work around this .... π
-
#FreeBSD users can get a #port of #dos2ansi v1.4 here, patch applies to the ports tree with `git am` (hint, use a local git branch to avoid cluttering your `main`):
https://people.freebsd.org/~zirias/patches/0001-textproc-dos2ansi-Add-new-port.patchThe port comes in two flavors: "nox11" makes #showansi optional and doesn't add any dependencies. "x11" (the default flavor) always includes showansi and adds runtime dependencies to #xterm and #ibmfonts, so the default configuration of showansi works out of the box.
Still unsure whether I should add it to the official ports tree .... π€
-
#FreeBSD users can get a #port of #dos2ansi v1.4 here, patch applies to the ports tree with `git am` (hint, use a local git branch to avoid cluttering your `main`):
https://people.freebsd.org/~zirias/patches/0001-textproc-dos2ansi-Add-new-port.patchThe port comes in two flavors: "nox11" makes #showansi optional and doesn't add any dependencies. "x11" (the default flavor) always includes showansi and adds runtime dependencies to #xterm and #ibmfonts, so the default configuration of showansi works out of the box.
Still unsure whether I should add it to the official ports tree .... π€
-
Two more examples using showansi from #dos2ansi v1.4:
1. Autoselecting a different codepage (here CP-855 cyrillic)
2. Autoselecting a "wide" font (here VGA-9x8, mapped to VGA18x16)
-
Two more examples using showansi from #dos2ansi v1.4:
1. Autoselecting a different codepage (here CP-855 cyrillic)
2. Autoselecting a "wide" font (here VGA-9x8, mapped to VGA18x16)