Troublesome rewriting of Unicode characters to HTML entities in RH 2022 CHM output
Hello,
The CHM output from RH2022 (2022.2.22) appears to assert compatibility with IE9 via meta X-UA-Compatible. Because X-UA-Compatible is IE9, the help viewer appears to render in IE9 mode, based on what I'm seeing in the F12 developer tools. (I did the whole enable-IE-compatibility-mode and manually launch iechooser.exe thing to hook up F12 to the help viewer.)
There are a number of places within our project (mainly compatibility/feature tables) that had raw checkmark characters (✓) or crosses (✗), and these appear to be getting rewritten--regardless of whether the source has the raw character, or the decimal &#nnnnn representation, or the hex &#xnnnn representation--to ✓ or ✗, which IE9 mode does not appear to render properly, instead just spitting the HTML entity text out. If I change the mode to IE10 or 11 in F12, those entities render properly.
Note that if I fiddle with the live contents in F12 and enter either of the character code formats and press Ctrl+Enter to update the page with my change (to make it match my topic's source), the character is displayed properly in IE9 mode. It appears that RoboHelp is trying to be helpful by rewriting working code to something ostensibly more readable/developer-friendly but that does not actually work.
The production version of this project, output using RH2019, seems to only transform the raw characters in our source to the decimal representation (e.g., ✓), which renders fine in the help viewer's IE5 mode and all later modes (when such modes are manually set within F12). For this reason, this change in behavior seems a lot like a regression to me.
I'm working around this by changing these characters to an image so we can eventually go into production with the RH2022 project, but it would be nice if RoboHelp would not output HTML entities that its supposedly-compatible IE version doesn't appear to understand. Using images is something I consider to be a temporary fix, as it degrades the experience of our Responsive HTML5 help if/when viewed on a high-DPI device, and also makes it less convenient to optionally color the symbols if we want to.
Thank you.
