I disagree. <br><br>RFC define grammar where menu entities are encoded in ASCII.<br><br>see <br><pre style="color:rgb(0,102,0)"><font size="4"><b>UNASCII ::= ASCII - [Tab CR-LF NUL].</b></font></pre>BUT latin-1 is ok ONLY for username part.<br>
<br><br><br><div class="gmail_quote">2012/5/5 Kim Holviala <span dir="ltr"><<a href="mailto:kim@holviala.com" target="_blank">kim@holviala.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On May 5, 2012, at 15:07 , Denis Bernard wrote:<br>
<br>
> Kim Holviala <kim@...> writes:<br>
>><br>
>> I rule!<br>
>><br>
><br>
</div><div class="im">> Â Your idea to provide IP address with host name and country is good... but<br>
> implementation  is not compliant with rfc-1436 as you are using the “i†item<br>
> type.<br>
><br>
>  You should generate your  message in a specific text file, hence using a “0â€<br>
> item type.<br>
<br>
</div>No need for that if I ever wanted to stuff with type "0". The server fully supports CGI's so it's just a matter of writing a script... Even autodetection between types 0 and 1 works farly well so the same script could just choose which format to output.<br>
<div class="im"><br>
>  I do not like “i†item-type, not only because it is not strictly compliant to<br>
> the standard, but because it is a bad idea for the small devices (like smart<br>
> phones).<br>
<br>
</div>The strict standard alse defines that all transfers end with a ".", but only very vaguely (it's been a while since I last read the RFC). If my memory serves me correctly the client just has to guess whether to remove the last dot or not...<br>
<div class="im"><br>
> Having nice ascii-arts is not good for the readability of menus for this small<br>
> displays! Making drawings in the menus is going in the same way that the Web<br>
> sites!<br>
<br>
</div>This I have to disagree, strongly. ASCII art has been with us 20 years before anyone even dreamed about graphics. It's old, just as old as terminal displays and hence I see no problem using it.<br>
<br>
Now, if the client decides to do "smart" reflow messing up the art then it's a client problem, not a server problem.<br>
<div class="im"><br>
> Â Run this to have a look at your gophersite:<br>
><br>
> www gopher://<a href="http://gophernicus.org/1/" target="_blank">gophernicus.org/1/</a><br>
><br>
> then, my own gophersite:<br>
><br>
> www gopher://<a href="http://oceamer.com/1/" target="_blank">oceamer.com/1/</a><br>
<br>
</div>As a counter-argument my site has no charset problems while yours looks like "événement". If you're optimizing for small devices then you cannot use anything else than 7bit US-ASCII. In fact, if you Obey The Law(tm) (well, the RFC) then you cannot use anything else either because it doesn't define any charsets to use. Historically everyone used Latin-1 so that's a good approximation, but that breaks with modern UTF-8 terminals.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
- Kim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Gopher-Project mailing list<br>
<a href="mailto:Gopher-Project@lists.alioth.debian.org">Gopher-Project@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Damien CAROL<br>
<a href="gopher://dams.zapto.org/1/" target="_blank">gopher://dams.zapto.org/1/</a><br>