Copy link to clipboard
Copied
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!
Copy link to clipboard
Copied
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!
Copy link to clipboard
Copied
Are both browsers up to date? Is the text garbled in any other languages?
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Thanks, Amebr. It is garbled both in local and published versions.
Copy link to clipboard
Copied
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"
Copy link to clipboard
Copied
Thanks for the reference! Will look in to this.
Copy link to clipboard
Copied
Did this just start happening or has it never worked? I'd suspect a font issue tbh
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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.)