Re: generate_html breaks documentation encoding

[Oliver Heimlich]

Am 17.01.2015 um 10:11 schrieb Julien Bect:
> Le 17/01/2015 09:16, Oliver Heimlich a écrit :
> > I debugged into the __makeinfo__ function and found the error: The
> > temporary file that is parsed by the system (cmd) should definitely
> > carry a @documentencoding utf-8 line at the beginning.
> >
> > I am going to post a patch in the bug tracker...
>
> I think there several issues there (at least two).
>
>
> Issue #1: which encoding is supposed to be used in the texinfo
> documentation of help functions ?
>
> __makeinfo__.m just adds a minimal header (\input texinfo) and footer
> (@bye), letting makeinfo decide.
>
> In other words, currently, Octave doesn't enforce any specific encoding.
>
> My opinion: if you use any "non-standard" character (say, anything
> outside the range 0x20-0x7E), you should insert a @documentencoding
> statement in your texinfo documentation to be safe.

Very good point! This resolves my problem and I will do that.

> If I understand correctly, you intend to enforce "@documentencoding
> utf-8" for all m-files. I don't know about that, but certainly other
> people on this list will have an opinion. The discussion will probably
> continue on the bug tracker if you propose a patch. An option would be
> to add "@documentencoding utf-8" only if another @documentencoding
> statement is not already present.

Since the utf-8 encoding in Octave is standard by accident [1] this 
would probably work, because most source files schould be encoded in 
utf-8. However, one would start to mess with texinfo input encoding.

I like your idea to explicitly label the documentation strings that are 
not encoded in us-ascii, which is the "latex way" to solve it.

[1] 
http://wiki.octave.org/International_Characters_Support#The_state_of_Octave

> Issue #2: generate_package_html() does not honor the "charset=utf-8" in
> the output of makeinfo
>
> I think this is a bug: generate_package_html() should honor whichever
> encoding comes out of makeinfo.
>
> I will fix this in the generate_html package.

I have checked the HTTP headers of the sourceforge web server. They do 
not enforce a particular encoding and the charset information in the 
html page can be changed.

Thanks for fixing ... and for your help with issue #1.