💾 Archived View for rawtext.club › ~sloum › geminilist › 005156.gmi captured on 2023-11-04 at 14:09:44. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Ascii art, accessibility, abstracts, more about environment ... was Re: Enviroments (was poetry)

Nico nico at itwont.work

Thu Feb 11 11:11:18 GMT 2021

- - - - - - - - - - - - - - - - - - -

On 10/02/2021 21:57, Miguel de Luis Espinosa wrote:

On Tue, Feb 9, 2021, at 12:38 AM, John Cowan wrote:

On Sun, Jan 31, 2021 at 7:20 AM Miguel de Luis Espinosa

<enteka at fastmail.com> wrote:

I've been giving some thought to how to share poetry and other, let's say, more typographically rich content in Gemini.

Can you explain more clearly what your poetry requires beyond the

plain-text formatting of ```...``` sections? The only thing I can

think of is that it will appear in a monowidth font.

Enviroments. We already have one: plain text. We could have something like

```

roses are red

this preserved space is not blue

so poetry you can do

```

The spaces should be preserved already because of the ```.

I have been thinking on this issue, going further than poetry, we could have environments for ASCII art. An ASCII art mark could tell the client, "hey client this is an ASCII art if you are some screen reader, you might want to skip this environment"

Abstracts, this could be redered by the client as a centered block perhaps

Poetry, which would be kinda monospace in the sense that it respects the spacing but could use some user chosen font (at configuration)

All in all, enviroments could be more like extra bits of semantic data than the client might want to use.

I feel like the plaintext block already covers all these use-cases, if you respect the ability to have alt-text for ascii art (which is in the spec). The only thing I can see being a legitimate addition is the ability to specify languages multiple times per file in some way.