From: gopher-bounce@complete.org Date: Sun Aug 10 02:07:46 2008 Subject: [gopher] Re: Gopherness How would we print a Gopher retreived text document on, for example, an older (or mini-mainframe) computer which only uses a Daisy Wheel Printer or Teletype Printer (which ONLY supports ASCII characters)? --- On Mon, 8/4/08, Nuno J. Silva <nunojsilva@ist.utl.pt> wrote: From: Nuno J. Silva <nunojsilva@ist.utl.pt> Subject: [gopher] Re: Gopherness To: gopher@complete.org Date: Monday, August 4, 2008, 2:08 PM "Jay Nemrow" <jnemrow@quix.us> writes: > On Mon, Aug 4, 2008 at 10:19 AM, Kyevan <kyevan@sinedev.org> wrote: >> What about older clients, though? Modern clients will probably handle >> UTF-8 at least well enough to not explode, but older clients might not. >> Generally, it seems safest to stick to the subset that is ASCII when >> reasonable, only using UTF-8 or such when it's actually needed. ... is a >> perfectly readable replacement for U+2026, even if it's not >> "typographically correct." On the other hand, if you're trying to post a >> text in, say, a mix of Arabic, and Klingon, go right ahead and use >> UTF-8. There are also these iso* charsets which just use 8 bit to encode the text, not allowing a greater collection of characters, and using those you wouldn't be able to mix charsets. For iso*, AFAIK, some sort of character detection, or configuration would be required on the client side (it is possible to do that getting the document language using gopher+ - and URLs pointing to the specific view (even if it is just one) would be required to autodetect when browsing a non-ASCII URL). utf8 will have to be supported, for the small (but not zero) scenarios in which two non-ASCII alphabets are mixed in the same text, and auto-detect would fail (unless a special language code is used for mixed-language documents, or if the client handles more than one non-english language (if it is allowed to specify more than one in the gopher+ attributes) as utf8). On the other hand, even if the choice was utf8 (so the documents would be ASCII or utf8), I'd keep iso* support, just in case (therefore my question is 'should we use the same sort of character encoding when publishing non-english documents? if yes, which one?' and not 'what should a client support?'). What's the actual scenario? Is there any client which crashes due to utf8? Which clients are not able to render it correctly? And what about iso* charsets support? <snip/> > If we do a version of Gopher which is basically new (adding UTF-8 or > MIME or whatever), I think we should ask for and get a new port > assignment for it. If you wanted Goph08, send the request through a > Goph08 port number. Gopher request continue to go through port 70. > Just have your server listen on two ports instead of one, using the > old idea that if you are using a different protocol (essentially), you > should use a different port. (Crazy idea, I know.) I guess this gets > back to an old point, which is that a modern version of Gopher is > essentially a new protocol and should be treated as such. If you guys > want to change Gopher to "improve" it, it ceases to be Gopher. > "Updated" nostalgia is not nostalgia at all. Adding a new way to do the mime part would be a reason to make another version of the gopher protocol, or a protocol under a different name, but about utf8, it's not about gopher, it's about the way text is rendered by the client, not requiring any change in the protocol. -- Nuno J. Silva (aka njsg) LEIC student at Instituto Superior Técnico Lisbon, Portugal Homepage: http://njsg.no.sapo.pt/ Gopherspace: gopher://sdf-eu.org/11/users/njsg Registered Linux User #402207 - http://counter.li.org -=-=- ``Now we'll have to kill you.'' -- Linus Torvalds