[CONTACT]

[ABOUT]

[POLICY]

Gemini Text Wrapping July minute

Found at: jfm.carcosa.net:70/blog/computing/gemini-text-wrapping-201907.txt

# Gemini Text Wrapping

July 14, 2019 ยท 3 minute read
      
Posted in:  gemini web gopher markup 

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

[1]: https://alexschroeder.ch/soweli-lukin
[2]: gopher://sdf.org/0/users/ratfactor/phlog/2019-06-09-gopher-2.0-markup





AD: