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.