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! 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. Scarlett tags: bencollver,retrocomputing,technical Tags ==== bencollver retrocomputing technical