utf-8 symbol problem with ellipsis

[khera]

In bug #4079 the bullet symbol is converted back to its unicode escape, \u25CF. The build.xml fixes the bullet at line 656.

The same treatment should be given to the horizontal ellipsis, …, which should be converted back to \u2026 as it appears in the source.

The problem this causes is if the page serving the chart is not encoded utf-8, the ellipsis displays as "…" for example. When you convert the ellipsis back to \2026 in the generated highcharts.js, it works just fine with or without utf-8 encoding of the pages. This is discussed in http://forum.highcharts.com/highcharts-usage/data-label-truncation-bug-related-to-encoding-of-ellipsis-t32965/

Alternatively, if you build highcharts without the charset UTF-8 option to the Closure compiler, it will not convert the unicode escape sequences into utf-8 characters, and the fixups are not necessary. These are the only two characters that are non-ascii in the generated file from Closure. The YUI compressor does not convert the \u codes into utf-8 characters so the charset flag to it doesn't matter, but is unnecessary.

[khera]

To be clear, this affects current versions of Firefox, Safari, and Chrome, not just legacy browsers like IE8, as mentioned in the referenced ticket.

[khera]

Another note: the Closure compiler --charset option sets both input and output character sets, but the default input character set is already utf-8, so removing this option from the command line does indeed seem like the right solution, and will not affect any possible utf-8 in the source files.

You can verify this by running the following hello.js script thru the compiler with and without utf8 character set flag. It contains the utf-8 ellipsis.

function hello(name) {
    // Greets the user
    alert('Hello, … ' + name);
}
hello('New user');

[brunocoelho]

+1

@highslide-software, any plans to investigate it?

[gilcarmel]

+1

[atungare]

+1

[Debga]

+1