Character-based icons not rendering in WebHelp Responsive
Posted: Sat Mar 16, 2019 5:52 am
We have a customer creating oXygen WebHelp Responsive output from DITA XML source. Generally, the system works very well.
The customer has deployed the help system to a server in a secure environment without access to the web.
Some of the characters used for help UI navigation refuse to render in the oXygen WebHelp font. In particular, the "double up" and "double down" chevrons used for "expand sections" and "collapse sections", immediately beside the "print" icon in the help topic, refuse to render. They render as plain "k" and "l" (lower case L) characters. It is as if the oXygen WebHelp font is not loading.
The client sees these warnings in the browser console:
Refused to load the stylesheet 'https://fonts.googleapis.com/css?family ... 00,700,300' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'style-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
topicFilename.html:1 Refused to load the font 'data:font/opentype;base64,{snipped the base 64 code for legibility}' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.
topicFilename.html:1 Refused to load the font 'data:font/opentype;base64,{snipped the base 64 code for legibility}' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.
topicFilename.html:1 Refused to load the stylesheet 'https://fonts.googleapis.com/css?family ... 00,700,300' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'style-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
They are using Google Chrome Version 72.0.3626.109 64-bit.
While these appear to be Content Security Policy (CSP) warnings, if a CSP somewhere is saying "Hey, you're not allowed to self-load fonts", then ALL of the character-based icons in the help system would render as their plain Latin characters. But that's not what is happening -- this only affects the "double up" and "double down" chevrons.
I do not have access to the client's test environment. I cannot replicate this problem on any of my test environments.
If it is a CSP that is causing this, I do not think that I can get the client to change their CSP to allow the help system to self-load resources like this. I am thinking that my only alternative is to replace all of the character-based buttons with graphics. I'd rather not do that.
Any suggestions on the cause and how to correct this?
Thanks -- Jonathan Piasecki
Precision Content Authoring Solutions, Inc
The customer has deployed the help system to a server in a secure environment without access to the web.
Some of the characters used for help UI navigation refuse to render in the oXygen WebHelp font. In particular, the "double up" and "double down" chevrons used for "expand sections" and "collapse sections", immediately beside the "print" icon in the help topic, refuse to render. They render as plain "k" and "l" (lower case L) characters. It is as if the oXygen WebHelp font is not loading.
The client sees these warnings in the browser console:
Refused to load the stylesheet 'https://fonts.googleapis.com/css?family ... 00,700,300' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'style-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
topicFilename.html:1 Refused to load the font 'data:font/opentype;base64,{snipped the base 64 code for legibility}' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.
topicFilename.html:1 Refused to load the font 'data:font/opentype;base64,{snipped the base 64 code for legibility}' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.
topicFilename.html:1 Refused to load the stylesheet 'https://fonts.googleapis.com/css?family ... 00,700,300' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval'". Note that 'style-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
They are using Google Chrome Version 72.0.3626.109 64-bit.
While these appear to be Content Security Policy (CSP) warnings, if a CSP somewhere is saying "Hey, you're not allowed to self-load fonts", then ALL of the character-based icons in the help system would render as their plain Latin characters. But that's not what is happening -- this only affects the "double up" and "double down" chevrons.
I do not have access to the client's test environment. I cannot replicate this problem on any of my test environments.
If it is a CSP that is causing this, I do not think that I can get the client to change their CSP to allow the help system to self-load resources like this. I am thinking that my only alternative is to replace all of the character-based buttons with graphics. I'd rather not do that.
Any suggestions on the cause and how to correct this?
Thanks -- Jonathan Piasecki
Precision Content Authoring Solutions, Inc