My understanding is that you can use special ANSI markup/escape
characters to indicate colours.
What is the correct mime type or encoding should be used for this?
Some pages in gemini just seem to apply it in the expectation clients
will expect it or know how to parse it, but it is not part of the Gemini
spec, and is a terminal thing only. It seems like sending html markup in
the middle of a text/gemini file and expecting a client will handle it
Should such pages be served with a specific mime type or encoding to
definitively indicate this?
It's an interesting question. Personally I'd recommend against
using it very much, unless it's just for fun on one page or something.
But I would advise against using it regularly in gemlog posts or something
As for mimetype and encoding, I think sticking with text/gemini and UTF-8
is good. Above all, just don't expect clients to render it properly. Some
will and some won't.
> On Jul 10, 2020, at 18:00, Luke Emmet <luke at marmaladefoo.com> wrote:
> Should such pages be served with a specific mime type or encoding to definitively indicate this?
My 2?: avoid ANSI escape sequences like the plague. Just say no. Leave it to the terminal kamikaze.
> On Jul 10, 2020, at 18:03, colecmac at protonmail.com wrote:
> Above all, just don't expect clients to render it properly. Some
> will and some won't.
Furthermore, avoid any terminal based client which merely dump raw ANSI escape codes at you. Like in many aspects of life, sanitization it key.
git: client prints server-sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1000021https://public-inbox.org/git/20180205204312.GB104086 at aiede.svl.corp.google.com/
On Fri, 10 Jul 2020 at 19:00, Luke Emmet <luke at marmaladefoo.com> wrote:
> My understanding is that you can use special ANSI markup/escape
> characters to indicate colours.
You can, in terminals with ANSI support. Some Gemini clients might
even let ANSI sequences through, but they'd be wise to strip them for
> What is the correct mime type or encoding should be used for this?
text/x-ansi seems to be used for ANSI art. That's what
On 2020-07-10 (Friday) at 11:38, Hannu Hartikainen <hannu.hartikainen+gemini at gmail.com> wrote:
> You can, in terminals with ANSI support. Some Gemini clients might
> even let ANSI sequences through, but they'd be wise to strip them for
> text/gemini content.
I know that with bollux at least (and I think Castor, at least last time I checked, though it's been a while), only the SGR parameters are passed through. That's done automatically with less in bollux, but there are libraries for other languages that can apply highlighting.
Of course, I agree that ANSI escapes should be used *very* sparingly, if indeed at all.
On 7/10/20 4:42 PM, Case Duckworth wrote:
> Of course, I agree that ANSI escapes should be used *very* sparingly, if indeed at all.
You can also do like astrobotany and offer a "fancy" version and a regular one. Konpieto used to offer a "spicy" version with ansi color. I like that approach as it doesn't get in the way but it can be fun for those who can see the colors.
My 2 cents:
Colors are really fun for those in terminal clients that support them,
but seem to be a pain to build out for graphical clients. So expect
failure. I really loved Konpeito's color banner and really like occasional
touches of color. However, full pages of colors tend to get weird.
Subtle is the way to go to provide a splash of fun.
My client, Bombadillo, has 'normal' and 'color' modes. In normal
mode all escape sequences are stripped from text/gemini output.
In color mode escape sequences dealing with color and text style
(but not placement) are rendered as the escape sequence so that
the effect can be seen.
I advise client authors to strip escape sequences if they do not wish
to deal with color output or terminals potentially getting really
On 10-Jul-2020 17:38, Hannu Hartikainen wrote:
>> What is the correct mime type or encoding should be used for this?
> text/x-ansi seems to be used for ANSI art. That's what
> gemini://ansi.hrtk.in/ serves.
Thanks for all your replies
My reading of the situation now is as follows:
ANSI escape sequences should not be interpreted within text/gemini
content (after all when would it stop - there could be embedded html or
other markup that clients will become expected to interpret). Similarly
they should not be stripped out - since how would one know they were
there, and should be intepreted rather than just presented. |On a Gemini
page I might say something like: "Is this the correct code to make all
text black: \033[30m ?" But I dont want to make the rest of my page
black by doing so
In terms of where these sequences may be interpreted or stripped out
there seem to be 3 candidates:
1. content served as text/x-ansi - e.g. for ANSI art
2. content in a preformatted range with the label indicating it as
text/x-ansi - we dont have a semantics or convention for this yet, but
it would be nice, like this maybe:
3. content served as some hybrid gemini format like text/gemini+x-ansi
I guess the general points of non-extensibility come up - would this
become a de-facto expectation for clients to implement? Could there be
other formats like text/gemini+html?
On Sun, 12 Jul 2020 at 11:50, Luke Emmet <luke at marmaladefoo.com> wrote:
> ANSI escape sequences should not be interpreted within text/gemini
> content (after all when would it stop - there could be embedded html or
> other markup that clients will become expected to interpret). Similarly
> they should not be stripped out - since how would one know they were
> there, and should be intepreted rather than just presented.
IMHO if a client is outputting to an ANSI terminal, the client author
should consider what will happen with ANSI sequences. It is reasonable
to strip or escape all of them, or a subset of them, or decide to let
them through. Consider that a terminal UI is itself built with ANSI
escapes and rendering them within the page could break the UI (or
worse, emulate the UI!). Moreover, you'd need to fully parse the
sequences and emulate terminal state to implement a sandboxed version
of ANSI sequences (unless you limit to a subset, say, SGR). I learned
that when trying to render 80-column ANSI art on wider terminals
(ansi.hrtk.in does that but background colors leak).
Similarly, if I was writing a Gemini-over-HTML proxy I'd certainly
escape all HTML tags and entities. First, it makes sense to show the
content to the user instead of interpreting it as control sequences.
Second, I've learned on the web that rendering any user-supplied
content without sanitizing will result in a disaster.
Gemini is still small and friendly, but when designing software it's
smart to account for bad actors.
PS. I just added yet another ANSI streaming server,
gemini://asciinema.hrtk.in/ for playing back asciinema.org recordings.
Probably only useful as a tech demo or a client test.