Re: UTF-8 output

[Matthias Clasen <maclas gmx de>]

On Fri, 2002-11-15 at 07:55, James Henstridge wrote:
> jrb pointed this issue out on IRC.  If you look at the documentation at:
>     http://developer.gnome.org/doc/API/2.0/glib/index.html
> 
> You will notice that it doesn't display the "Next >>>" link correctly 
> (there is a little bit of garbage between "Next" and ">>>").
> 
> I investigated this problem, and it is because mozilla is interpreting 
> the web page as being Latin1, while it is actually UTF-8 encoded (the 
> garbage is the UTF-8 representation of a non-breaking space).  This 
> seems to be due to a conflict between the headers sent by the web 
> server, and the <meta> tag in the page itself:
> 
>     Content-Type: text/html; charset=ISO-8859-1
>     <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> 
> The http headers take precedence, and disables the browser's encoding 
> detection routines.  This could be a a fairly common problem for gtk-doc 
> generated content, as many web servers send an encoding with all pages 
> these days due to some security bugs, and will cause problems for any 
> characters in the document outside of the 7-bit ASCII range.
> 
> The bug mentioned in the change log related to this change is here:
>     http://bugzilla.gnome.org/show_bug.cgi?id=94833
> It is not clear to me what problem this was fixing.  When gtk-doc was 
> outputting latin1 documents, wasn't it correctly encoding non-latin1 
> characters as character references?

No, the problem I have fixed was that gtk-doc is emitting UTF-8
documents, but not correctly putting the charset in the meta tag. That 
fixed the garbage problem in my local tests - since no web server was
involved. If web server configuration commonly works against inline
encoding information, it might be better to change gtk-doc to emit
iso8859-1 and use numeric character references for anything beyond that
range. Should be a one line change in gtk-doc.xsl.

Matthias