Re: [Docutils-develop] Re: utf-8 default == bad!

[<gr...@us...>]

On Wed, 14 Apr 2004, David Abrahams wrote:

> David Abrahams <da...@bo...> writes:
>
> >> The output is not pure ASCII.  The "section-numbering" directive
> >> inserts non-breaking spaces into the output.
> >
> > And what's not pure-ASCII about "&nbsp;"?

davidg , why not "&nbsp;" ?

> >> Try "--output-encoding-error-handler=xmlcharrefreplace".
> >
> > Whaa??  I guess I'll need to read the help.  Oh, that's not in the
> > output of html.py --help.  Where do I find it?  What does it do?
>
> OK, I see what it does.  I'm trying Latin-1 encoding for now, to see
> if the server is more receptive.
>
> I'm not convinced that utf-8 is a bad default anymore, but I do wonder
> how many times people have been bitten by this one.  I remember being
> surprised early on that htmltidy couldn't validate docutils output,
> for example.  Maybe it would be interesting to insert a comment in the
> top of utf-8 encoded html that describes how to deal with the issue on
> the command-line?  Just fishing for a solution here...

the http://tinyurl.com/2qtkk server tells in the header ::

  Content-Type: text/html; charset=iso-8859-1

the document itself says ::

  <?xml version="1.0" encoding="utf-8" ?>
  ...
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

so the browser has several options, the one from the server is plainly
wrong. maybe the browser would take the "<meta" thing if you delete the
xml line ? BLIND GUESS only.

i have a worse problem with docbook how to tell it that the text is in
russian ? configuring the server solved it but this means offline reading
might be impossible if the browsers default is not koi-8r and how to tell
it tex ... ?

cheers

-- 
 BINGO: aggressively priced next-generation critical mass