💾 Archived View for gemi.dev › gemini-mailing-list › 000289.gmi captured on 2024-08-19 at 00:07:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hello all 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 correctly. Should such pages be served with a specific mime type or encoding to definitively indicate this? thanks - Luke
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 like that. 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. makeworld
> 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. For example: 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-1000021 https://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 text/gemini content. > 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. -Hannu
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[1] 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 donked.
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: ```art;content-type=text/x-ansi 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? Best Wishes - Luke |
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. -Hannu 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.
---