Legacy Support Options (16 colors & ASCII encoding)

TODO

• 16 colors mode (option colors=2|16|256|true, 256 by default)
• output encoding (option encoding=, utf-8 by default)

Details

First, let me say I love this app. It produces lovely results on the command line.

I run a telnet BBS and would love the ability to curl the output of wttr.in to an ANSI file, so that said ANSI file can be viewed by users on my BBS. However, two things are stopping me from doing that:

1. The BBS software I’m using (Synchronet, and probably most others) has no support for 256 color ANSI escape codes used in wttr.in’s output. As far as I can tell, the BBS software only supports the legacy 16 color escape codes.
2. The output encoding of wttr.in (I’m guessing) is strictly UTF-8, which also does not render properly in the BBS. While I can set curl’s encoding to ASCII, the line-drawing characters do not translate properly when using that option.

To try to illustrate both issues, I’ll use the command curl wttr.in/NYC?n -o sample.ans to generate a sample ANS file. When viewing the resulting sample file in the ANSI editor PablowDraw, the attached screen is what displays.

If there were parameter options for both selecting either 16 or 256 color codes and selecting either ASCII or UTF-8 character encoding, that would produce great results that BBS sysops would love.

[chubin]

Yes, I think both are doable. I updated the issue description, added both feature requests to it.

It will be possible to specify these two parameters with the following options:

• encoding=
• colors=

[CraigEMP]

@CraigEMP Accepted 16-colors request.

Nice, thank you!

Now about the encoding:

what what be the best solution?

1. ASCII Only (see: #432, #113, #197, #221)
2. No frames
3. Encoding can be specified as the parameter

Of the issues listed in your ASCII Only option, issue #432 is doable, as it’s most similar to what I’m asking for, however it seemingly does not ask to keep support for the box and line drawing characters within Codepage 437, which make ANSI tables look very nice.

(side note: we should be careful to not conflate plain-text discussed in issues #113 and #197 with ASCII encoding; ASCII != plain-text)

The frameless display could be a decent workaround, but there are other characters that would still get interpreted incorrectly, like the degree and wind direction symbols, as well occasional dashes used for the sun’s rays (another screenshot attached).

Specifying the encoding sounds ideal, if it’s doable.