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, 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, 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.