Do you have an issue with a specific file(s)? DOCX
Can you reproduce using one of our samples or online demos? No
Are you using the WebViewer server? No
Does the issue only happen on certain browsers? All browsers
Is your issue related to a front-end framework? No
Is your issue related to annotations? No
Please give a brief summary of your issue:
Loading an office document into Webviewer with disableBrowserFontSubstitution does not substitute the fonts using my fonts.json.
Please describe your issue and provide steps to reproduce it: Core.setCustomFontURL(…)
I am expecting the fonts on the loaded docx document to be substituted with fonts as defined in my fonts.json. My expectation comes from this documentation. Instead, I see no request to my custom font URL and the document loaded into webviewer still has its system fonts. Just a note that I do see a request to my custom font URL when I save the loaded document as a PDF from the webviewer UI.
My custom fonts are not loading at all when I load a DOCX file into webviewer. There is no request in the network tab to get the fonts.json file. However there is a successful request to fonts.json when I save the loaded DOCX file as a PDF in webviewer. Therefore I know my Core.setCustomFontURL(…) and fonts.json are correct.
Additionally the officeOptions: { disableBrowserFontSubstitution: true } has no effect, system fonts are still used for the loaded DOCX document. The webviewer documentation states that should not be the case.
By default, office viewing takes a lightweight approach to font substitution, allowing the browser to select fonts when they are not embedded in the document itself. While this means that WebViewer has access to all the fonts on the user’s system, it also means that an office document may have a different “look” on different systems (depending on the fonts available) and when it is converted to PDF (as the PDF conversion routine cannot obtain low-level access to user fonts, for security reasons). disableBrowserFontSubstitution prevents this browser substitution, forcing the WebViewer backend to handle all fonts. This means that viewing and conversion to PDF will be 100% consistent from system-to-system, at the expense of a slightly slower initial viewing time and higher bandwidth usage. Using Self serving substitute fonts | Apryse documentation along with this option allows you to fully customize the substitution behaviour for all office files.