Okay, I'm going to update the spec-spec this weekend to replace the current RFC-1896 text wrapping with the new "wrap long lines but don't join short lines" approach with everybody seems either to agree is an improvement or to feel indifferent about, and which nobody objected to for 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 remove ambiguity or anything like that? Cheers, Solderpunk ``` 1.3.5.3 Text display Textual content for Gopher is typically "hard-wrapped", i.e. composed of lines no longer than (typically) 80 characters. Each line of text is printed to the screen as-is. In contrast, in HTML content on the web, browsers ignore the length of lines of text and instead "reflow" text to a width appropriate for the display device - lines of text in a HTML file which are "too long" get split up, while consecutive lines which are "too short" get joined together. Gemini adopts a strategy between these two approaches, designed to strike a balance between implementation complexity, flexibility of display width, and support 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's display device SHOULD be "wrapped" to fit, i.e. long lines should be split (ideally at whitespace or at hyphens) into multiple consecutive lines of a device-appropriate width. Recall that text/gemini processing is strictly line-based: the above wrapping is applied to each line of text independently. Multiple consecutive lines which are shorter than the client's display device MUST NOT be combined. Blank lines receive no special treatment: they are ordinary text lines, with a display length of zero. Thus, they fit on any client's display device and never need to be wrapped. Each individual blank line in a text/gemini document MUST be rendered by the 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 a specific fixed width. Most text editors can be configured to "soft-wrap", i.e. to write this kind of file while displaying the long lines wrapped to fit the author's display device. Authors who insist on hard-wrapping their content MUST be aware that the content will display neatly on clients whose display device is as wide as the hard-wrapped length or wider, but will appear with irregular 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
---
Previous in thread (147 of 148): 🗣️ solderpunk (solderpunk (a) SDF.ORG)