💾 Archived View for rawtext.club › ~sloum › geminilist › 000422.gmi captured on 2020-10-31 at 01:34:10. Gemini links have been rewritten to link to archived content

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

Text reflow woes (or: I want bullets back!)y

solderpunk solderpunk at SDF.ORG

Sat Feb 1 18:00:34 GMT 2020

- - - - - - - - - - - - - - - - - - - ```

Okay, I'm going to update the spec-spec this weekend to replace thecurrent RFC-1896 text wrapping with the new "wrap long lines but don'tjoin short lines" approach with everybody seems either to agree is animprovement or to feel indifferent about, and which nobody objected tofor the past week or so either on this list or to me directly.

My plan is to replace the entirety of section 1.3.5.3 with the below.Does anybody want to suggest any minor changes to this text to removeambiguity or anything like that?

Cheers,Solderpunk

Textual content for Gopher is typically "hard-wrapped", i.e. composedof lines no longer than (typically) 80 characters. Each line of textis printed to the screen as-is. In contrast, in HTML content on theweb, browsers ignore the length of lines of text and instead "reflow"text to a width appropriate for the display device - lines of text ina HTML file which are "too long" get split up, while consecutivelines which are "too short" get joined together. Gemini adopts astrategy between these two approaches, designed to strike a balance between implementation complexity, flexibility of display width, andsupport for common text formatting patterns.

Lines of text in a text/gemini document which are not link lines (i.e.do not begin with "=

") which are longer than can fit on a client'sdisplay device SHOULD be "wrapped" to fit, i.e. long lines should besplit (ideally at whitespace or at hyphens) into multiple consecutivelines of a device-appropriate width. Recall that text/geminiprocessing is strictly line-based: the above wrapping is applied toeach line of text independently. Multiple consecutive lines whichare shorter than the client's display device MUST NOT be combined.

Blank lines receive no special treatment: they are ordinary textlines, with a display length of zero. Thus, they fit on anyclient's display device and never need to be wrapped. Eachindividual blank line in a text/gemini document MUST be rendered bythe client as an individual blank line.

In order to take full advantage of this method of text formatting,authors of text/gemini content SHOULD avoid hard-wrapping to aspecific fixed width. Most text editors can be configured to"soft-wrap", i.e. to write this kind of file while displaying the longlines wrapped to fit the author's display device.

Authors who insist on hard-wrapping their content MUST be aware thatthe content will display neatly on clients whose display device is aswide as the hard-wrapped length or wider, but will appear withirregular line widths on narrower clients.```

On Thu, Jan 23, 2020 at 11:13:51AM +0000, solderpunk wrote:

On Wed, Jan 22, 2020 at 11:51:37PM +0100, Brian Evans wrote:

So long as it is not a mandate, but an optional part of the spec, I

withdraw my objection.

I don't intend anything to be mandatory except link lines, ordinary text

lines and possibly ``` raw/verbatim/preformatted handling (I'm not 100%

sure on that last one, I think perhaps switching to wrapped long lines

as the official recommendation removes many of the justifications we

had for first proposing it - though certainly not all of them).

Anything to do with headings, lists, etc. will be strictly optional, and

a major factor in whether I decide to adopt any of those things will be

how well they degrade when viewed on a simple terminal-based client

which completely ignores all optional components.

All I've ever wanted is to permit improvements to readability or

navigation in advanced (possibly, but not necessarily, graphical)

clients as much as possible without interfering in any non-trivial way

with the usability of incredibly simple clients.

Cheers,

Solderpunk