(TXT) View source
       
       # 2024-02-19 - Gopher Formatting
       
       I've been reading posts in the gopherverse with opinions about how to
       format gopher content.  I figure part of the appeal of gopher is that
       its design pre-dates the commercialization of the Internet.  Likewise
       in that era the Internet was flying under the radar.  It had room for
       ideals like anarchy, decentralization, and dissenting opinions.
       
       A year or two ago, i read strong opinions about how to format content
       for gopher.  The two main positions are A) RFC1436 and also reference
       client only display 70 characters of text, so hard wrapping is polite
       and preferrable, and B) mobile devices are the new normal and content
       should be designed for mobile users.
       
       I sat and thought for a while, and it occurred to me that web browser
       tech doesn't care whether you hard-wrap text.  It re-flows / re-wraps
       the text to fit the display.  Long lines, short lines: irrelevant.  I
       wrote a proof-of-concept script to hard wrap and unwrap text and then
       ran it to convert my site from gemtext to gophermaps and back.  After
       seeing this successful round-trip, i hard wrapped my content and have
       not looked back.  I also wrote algorithms to split long URLs in a way
       that is human readable and join them back together into working links
       in gophermaps.
       
       So far as i am concerned, it is a contrived dichotomy, a rare & happy
       circumstance where there IS a technical solution.  It's way easier to
       change software than to change minds.
       
       There are drawbacks to using a protocol designed in an earlier era of
       the Internet, too.  For example, internationalization was clearly not
       a design goal.  Here too, this is a happy circumstance where there is
       a technical solution and most client software has already implemented
       it.  Just take the spec and replace the word "Latin" with "UTF-8".
       
       Recently i wrote a script to validate gopher maps.  When reporting on
       potentially problematic gopher text, it gives references.  One of the
       things it reports is using gopher maps for content, versus navigation
       as some clients cannot be used in this way.  I totally understand why
       people would want to use gopher maps for content.  This preserves the
       familiar metaphor of hypertext that blends links inline with content,
       as is done on the web.
       
       Here i do not see a happy technical solution.  Either i use gopher as
       it was originally designed, and i separate content from navigation OR
       i can approximate the web experience and exclude users of old classic
       computers and software of that era.  As a workaround, i put a link at
       the top of my content to "View source," which in my case is plaintext
       markup that my script converts to a gophermap.  My gopher maps do not
       pass my own validation script, but they ARE viewable in UMN gopher by
       using the "View source" menu option.
       
       Below is a link to my validation script in case anyone is interested.
       I welcome feedback!
       
 (TXT) gopher-validate.awk
       
       ## 2024-03-30 update
       
       I found another person taking the same approach.  My top most link is
       "View source" and theirs is "(ASCII version)".  Our plaintext / ASCII
       versions use similar but not identical markup conventions.  See below
       link for examples.
       
 (DIR) Scarlett
       
       tags: bencollver,retrocomputing,technical
       
       # Tags
       
 (DIR) bencollver
 (DIR) retrocomputing
 (DIR) technical