headers
Cameron Kaiser | 1 Oct 2008 01:19
Favicon

Re: Multilingual Gopher Support (was Re: Gopherness)

> I switched it to UTF-8 with BOM and although the BOM appears in FF2 =20
> (as a '?' at the start of the file), it now looks fine in lynx.
> The characters in question obviously weren't 7-bit ASCII, I had two =20
> '=C3=A9's on one line, and the output in lynx was that the links drawn =
=20
> didn't match the links that were highlighted when you pressed 'down', =20
> such that navigating the page produced erroneous drawing in the =20
> terminal.

I'm not surprised, Lynx does not have much history with non-7bit encodings.

> I have also since discovered that URLs such as /h/linguistics/yol=C5=8Bu/=
 =20
> are not requested correctly. No URL escaping of the unicode characters =
=20
> is performed, and ^K whatever that's supposed to mean: '/h/linguistics/=
=20
> yol^Ku' instead of  '/h/linguistics/yol%C5%8Bu/'.

You mean the client does not request them correctly, or the server does not
process the request correctly? I would probably call 8-bit Gopher handling
"undefined." However, if Unicode characters (or any non 7-bit entity) were
in a gopher selector, I don't think URL encoding them is really in the spir=
it
of the RFC either.

--=20
------------------------------------ personal: http://www.cameronkaiser.com=
/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser <at> floodgap.c=
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cameron Kaiser | 27 Oct 2008 03:32
Favicon

Overbite build 1419

I haven't heard back from the tester who submitted the original bug report,
so I'll pass it to the group. Overbite build 1419 is available which fixes
some small cosmetic issues, and has one big change, namely "dotless" mode.

"Dotless" is an internal filter to suppress the famous final full stop that
the Gopher protocol ambiguously asks for or not on textual transmissions, but
which can trip up markup language parsers (for example, the current build
downloads SVG images correctly, but the Mozilla image parser refuses to
display them if the trailing period gets added by the server). With "dotless"
enabled, which is the default in 1419, if the dot plus a variable amount of
trailing white space or newline/returns exist at the end, they are trimmed.
However, I don't want to completely eliminate transparency, so if the
preference extensions.overbiteff.dotless is present and set to false,
OverbiteFF will fall back on the old behaviour and will not try to filter
the trailing period.

I hope to release 1419 with the coincident release of Firefox 3.1, and then
start on Overbite 1.2 with XUL. However, as Firefox 2.0.0.x is now end of
life, 1.1.* will be the only supported version for Firefox 2, although I will
still make bug fixes and security patches against 1.1 for a period of time
after Mozilla ends Firefox 2/Moz 1.8 support.

--

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@...
-- 1-GHz Pentium-III + Java + XSLT == 1-MHz 6502. -- Craig Bruce --------------
Permalink | Reply | 0 comments |
headers
Cameron Kaiser | 27 Oct 2008 03:32
Favicon

whoops

Oh, the URL helps:

	gopher://gopher.floodgap.com/9/obff1419.xpi

--

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@...
-- "Bad dog, what a big mess you made! I told you to sit! SIT!!!" -- unknown --
Permalink | Reply | 0 comments |

Gmane