Troublesome rewriting of Unicode characters to HTML entities in RH 2022 CHM output

[Josh_Harmon]

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., &#10003), 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.

[Jeff_Coatsworth]

Hang on - I'm confused...are you creating CHMs or HTML5? 

[Josh_Harmon]

@Jeff_Coatsworth We create both, but as far as the issue goes, I'm primarily concerned with the CHM. The CHM ships with our software and we do context-sensitive linking into it, and Responsive HTML5 is posted on our website.

We make software for the ICS world. This means our software often runs on non-internet-connected devices that may not be patched/updated with any appreciable level of frequency, so leveraging a pre-installed core OS component like MSHTML works great for the offline use case.

[Jeff_Coatsworth]

Ok, so are these characters part of a different font that you're using? Maybe it's the way that font is being handled that is responsible. You don't mention if, when it was working with RH2019, whether you were using the Classic or New UI version - if it was the New UI, then I'd be contacting the RH folks with the issue. If it was Classic, then it could be some issue in the way the project was converted (just taking a guess).

[Josh_Harmon]

Nope -- I'm not doing anything weird like leaning on a specific font or anything like that. The font is the (seemingly-)default of Verdana both in the old and new CHMs. Like I mentioned, I can edit the HTML in F12 without changing the font and the characters render fine.

That being said, thanks for pointing out the Classic or New UI thing. I didn't know there were two versions of 2019. We were using Classic in 2019, so it wouldn't be surprising if the origin of this behavior change was in the New 2019 but we just never ran into it until now. (For context, I'm just a software engineer who was recently pulled into this project because our normal help writers don't know enough HTML/CSS/JS to fix the things that changed/broke during the upgrade.)

Anyway, I'll fire off an email to tcssup -- thanks for sharing some ideas and prompting some additional details for me to provide to them!

[Jeff_Coatsworth]

If your RH2022 is patched up with Patch #2, I'd try a test of upgrading a copy of the RH2019 Classic project again.

But doing a quick google, those characters you show - Check Mark (U+2713) and Ballot X (Cross) (U+2717) - don't appear to be supported by Verdana. I'd go back & have a look at the source RH project where they are being used.