RoboHelp 2019 Output Garbled Text in IE and Firefox

[dfoster707]

Using RoboHelp 2019 Release Version 14.0.14 (up to date). We have discovered that the frameless output for our two translated projects (Japanese and Spanish) are displaying garbled charactes when viewed in Internet Explorer and Firefox (no issues in Chrome or Edge). Looking back at local archived builds, this issue began towards the end of June 2020. Local archived builds prior to that display fine in all browsers. Builds produced after that display garbled characters in IE and Firefox (as attached).

Language settings in frameless output are set correctly; encoding settings set to default, and neither of these settings changed prior to or after June. Changing them yields no effect. This does not affect our English project, only our Japanese and Spanish projects. Manually changing the browser Encoding setting to Unicode resolves this in IE, but does not resolve in Firefox.

Has anyone dealt with this issue before? Anything come to mind that might help? Many thanks!

[Jeff_Coatsworth]

Are both browsers up to date? Is the text garbled in any other languages?

[dfoster707]

Browsers are up to date and this experience has been reported by multiple customers and reproduced internally on both local and deployed builds. The text is only garbled for these two languages. Our final English build displays correctly.

[Amebr]

Is the content garbled when you view locally or only web published to the web server? If it's only on the web server, I would check with the server admin what the encoding from the server is. The look is consistent with the server setting something other than utf-8.

[dfoster707]

Thanks, Amebr. It is garbled both in local and published versions. 

[Amebr]

Here's a good reference:

https://www.w3.org/International/questions/qa-headers-charset.en

"Note...the encoding declared in the HTTP header overrides all in-document encoding declarations in HTML and CSS files"

[dfoster707]

Thanks for the reference! Will look in to this.

[Jeff_Coatsworth]

Did this just start happening or has it never worked? I'd suspect a font issue tbh

[dfoster707]

Based on testing my local saved build outputs, it began happnening sometime in June of this year, but was not noticed/escalated to us until recently. We did upgrade to the March release at the start of June, and then to the most recent release in September. Aside from these software updates, we didn't change anything in the projects, which have been in use for years now, and were upgraded to the 2019 frameless output without issue over a year ago. 

[Amebr]

Hmm, if it's happening on your C drive, then it's not the http headers, although it does look like an encoding problem.

A bit of clutching at straws, can you open a problem source topic in a text editor like Notepad or Notepad++ and have a look at the meta tags for a charset value. Does it say utf-8 or something else?

Don't use the HTML view in Robohelp because it doesn't show reality in this case. (I tested by manually changing the value in Notepad++, but RH continued to show what it expected, not what the value was.)

[Amebr]

Actually, ignore that. It won't affect the skin.

I did manage to get the whacky characters in a RH Classic (14.0.12) project by changing the charset in the homepage.slp. But you said you're using Frameless which means RH New UI (2019.0.14), so how I did that isn't possible in New UI. I'll have more of a think.

[Amebr]

In the Preset, what's the Encoding field set to?

[dfoster707]

The Endoding field set to Default, which is what it's been set to for the duration of the project (years). What we discovered comparing output htm files from before this issue began and after is that the following charset metadata is now missing:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

The only thing that changed  from before and after the issue appeared is our upgrade of RoboHelp to the March release in June. No other settings were changed in the projects, and indeed, very little content was changed. We've opened a support ticket with this information.

[Peter Grainge]

I have spoken to Adobe on the general issue of IE support. My understanding is as below.

I understand from Adobe that the issue here is likely to be IE's support for the CSS3 and advanced HTML5 features used in the new UI versions of RoboHelp.

IE8 is not supported. Whilst some compatibility with IE11 has been added, advanced features may still not work.

For 2019 New UI and 2020 Chrome, Edge and Firefox should be used.

In your case I see you are also having issues with Firefox so unless the various answers provided by others solve the issue, I suggest you take it up with Support.

See https://helpx.adobe.com/contact/enterprise-support.other.html#robohelp for your support contact options.

________________________________________________________
See www.grainge.org for free Authoring and RoboHelp Information

[dfoster707]

We opened a support ticket to inform them that the following charset metadata is now missing from our files after we upgraded RoboHelp 2019 to the March release in June:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

No other settings were changed in the projects and the upgrade is the only difference from before and after the issue appeared.

[Jeff_Coatsworth]

My suspicion is that, like a lot of other dropboxes, the <Default> setting you see, actually is a blank in the data & when you upgrade, the conversion process gets confused as to what's actually desired in that field - thus the missing line when you generated in the output.