Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong character encoding in HTMLHelp contents (Origin: bugzilla #498703) #2729

Closed
doxygen opened this issue Jul 1, 2018 · 0 comments
Closed

Comments

@doxygen
Copy link
Owner

doxygen commented Jul 1, 2018

status RESOLVED severity normal in component general for ---
Reported in version 1.5.4 on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

On 2007-11-21 09:42:17 +0000, Peter Waszkewitz wrote:

Please describe the problem:
In a German HTMLHelp file, the "Related Information" entry is "Zusätzliche Informationen". It appears correct in the text but in the contents tree view, the special German character is represented as a two-byte UTF-8 sequence.

Steps to reproduce:

  1. Create a doxygen project with a standalone \page so that a "Related information" section appears
  2. Set the output language to German
  3. Compile to chm

Actual results:
Related information is correctly translated, displayed correctly in the HTML text, but with a wrong character in the tree view.

Expected results:
To have it appear with the correct character in the tree view.

Does this happen every time?
yes

Other information:
It appears that hhc.exe supports UTF-8 in the html topic files but not in the hhc file. I could not fix it by editing the hhc file to have UTF-8 encoding. However, using the ä character entity in the hhc file fixed it without any other changes to the HTMLHelp project. So I guess that translating special characters, if possible, to HTML character entities in the hhc file should fix it.

On 2007-12-15 22:10:54 +0000, Dimitri van Heesch wrote:

Can you check if this already has been fixed in the latest subversion update?
I corrected the character encoding for the various index file.
A binary for windows can be downloaded here: http://doxygen.sourceforge.net/dl/doxygen-1.5-cvs/

On 2007-12-19 11:28:24 +0000, Peter Waszkewitz wrote:

As far as I can see, it is not fixed. I can supply a project file and some source files to demonstrate the problem.

On 2007-12-20 10:18:18 +0000, Dimitri van Heesch wrote:

Please do. You can attach it to this bug report.

On 2009-01-19 14:17:30 +0000, Christoph Wurm wrote:

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!

On 2011-12-20 05:56:08 +0000, Sergey Enns wrote:

Created attachment 203930
test config

I found a small problem with encoding while generating HtmlHelp index file.
doxygen 1.7.1
Group name had written in UTF-8 though chm_index_encoding and input_encoding was setted as windows-1251
When i disable input_encoding hhk file generates normally, but contents of group stay unreadable (utf-8 default)

Now i use doxygen 1.5.6 where group description doesn't include in hhk file.
As hhc doesn't support utf-8 guess hhk values shouldn't be encoded.

On 2011-12-20 05:56:44 +0000, Sergey Enns wrote:

Created attachment 203931
test file with group definition

On 2011-12-20 05:57:54 +0000, Sergey Enns wrote:

Can't reopen this bug

On 2011-12-20 08:54:15 +0000, Dimitri van Heesch wrote:

Confirmed. Should be fixed in the next subversion update.

On 2012-02-25 15:37:41 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.0. Please verify if this is indeed the case. Reopen the
bug if you think it is not fixed and please include any additional information
that you think can be relevant.

On 2012-02-27 07:58:14 +0000, Sergey Enns wrote:

Good!It's ok in version 1.8.0.

@doxygen doxygen closed this as completed Jul 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant