Is the gemini map format intended to be reflowed?

One question that hasn't been addressed in the Gemini speculative specification

is whether the Gemini map file format `text/gemini` is intended to be reflowed.

By reflowed, I mean mainly that the line-length of the file itself is not

intended to be mapped exactly to the output device, which should instead lay out

the text with appropriate line lengths. This is what HTML renderers do, and what

MarkDown renderers do, usually by way of conversion to HTML.

This is currently a pain point in gopher: many/most gopher holes are written

with the assumption that the client is running in a text terminal or similar

environment, with a width of 80 monospace characters. If you accept this

assumption, and never reflow text, you can use whitespace for formatting, and

use ASCII art, which many gopher holes do.

However, this is an enormous pain on devices or clients that don't match that

assumption. Mobile clients, especially, have a hard time rendering 80 characters

wide. It wouldn't be hard to make them reflow all text documents, but that

would break ASCII art and similar formatting. Alex Schroeder has written a

web-based gopher client called Soweli Lukin[1], which has become my principal

way of browsing gopher on my phone. It is extremely good at guessing whether a

given "paragraph" is safe to reflow HTML-style and render in a proportional

font. But according to Alex, it is also full of scary edge-cases.

I'd like to preempt this problem by making it possible to specify unambiguously

at the paragraph level whether a paragraph should be reflowed. And to do so, I

would like to recommend that we accept a minimal text markup language as the

underlying format for Gemini maps. The format I want to recommend is Text

Junior[2], by gopher user ratfactor. It is similar to MarkDown, but is intended

to be simpler to implement, being purely line-oriented.

A terminal-based Gemini client could choose not to reflow `text/gemini`

documents and still be compliant. But authors should assume that text will be

processed according to Text Junior's rules. If you want to include ASCII art or

ASCII tables, you should put them in a

Making this decision will facilitate a diversity of clients., including native

mobile clients. And it emphasizes the principle that we are publishing

text-based documents for human beings, not just for text terminals.

Soweli Lukin

Gopher 2.0: Markup