Choose the right rendering and font troubleshooting workflow
Rendering and font issues can look similar in Nutrient Web SDK, Document Engine, and DWS Viewer API, but the right troubleshooting workflow depends on where rendering happens and who owns the font configuration.
The same troubleshooting goal in each setup
| Setup | Where rendering and font decisions happen | When to use it |
|---|---|---|
| Web SDK with a license key | Rendering happens in the browser. Font behavior depends on the source PDF, embedded fonts, browser environment, and any Web SDK font configuration. | Use this when your app opens documents directly in Web SDK without a server-backed rendering layer. |
| Web SDK + Document Engine | Rendering happens through Document Engine. Font behavior depends on the source PDF plus the fonts, substitutions, cache state, and server configuration in your deployment. | Use this when your app uses Document Engine as the rendering and persistence backend. |
| DWS Viewer API with DWS-managed documents | Rendering happens through DWS Viewer API for uploaded DWS-managed documents. Font behavior depends on the source PDF and the managed server-side rendering environment. | Use this when Nutrient stores and renders the document for your Web SDK integration. |
| DWS Viewer API with app-provided documents | The document is provided directly to Web SDK, so rendering troubleshooting is closer to standalone Web SDK than to DWS-managed diagnostics. | Use this when your app passes the file, URL, Blob, or ArrayBuffer directly to Web SDK instead of uploading it to DWS. |
How to choose the right troubleshooting workflow
Use Web SDK with a license key when the issue appears in a browser-rendered document and your app owns document loading and font configuration.
Use Web SDK + Document Engine when the issue may come from server-side rendering, mounted fonts, font substitutions, cache state, or other Document Engine configuration.
Use DWS Viewer API with DWS-managed documents when the document is uploaded to DWS and you need managed-service diagnostics such as document fonts, global fonts, substitutions, page render previews, and document metadata.
Use DWS Viewer API with app-provided documents when the document never becomes a DWS-managed document. In that case, troubleshoot it like a Web SDK rendering issue first.
Common points of confusion
- A font issue is often a document issue first — Missing embedded fonts, Identity-H encoding without usable Unicode mapping, broken font descriptors, or malformed PDFs can cause rendering differences across all setups.
- The same visual symptom can come from different layers — In Web SDK standalone, the browser-side viewer stack is the main surface. In Document Engine and DWS Viewer API managed flows, the server-side rendering layer is also part of the investigation.
- App-provided DWS documents are different from DWS-managed documents — If the file is passed directly to Web SDK, DWS document-diagnostics endpoints aren’t the primary troubleshooting path.
- Font availability and font substitution are separate checks — A missing original font doesn’t always mean a failure if a configured substitute is expected.
- Caching can hide fixes — After changing fonts or substitutions in a server-backed setup, old rendered output may still appear until caches are cleared or refreshed.
Typical decision questions
Ask these questions before choosing a rendering or font investigation path:
- Is the document rendered directly in the browser or through a server-backed rendering layer?
- Is the document DWS-managed, Document Engine-backed, or app-provided?
- Does the source PDF embed the expected fonts?
- Are custom fonts or substitutions configured in the rendering environment?
- Can the issue be reproduced in a direct rendered page image outside the viewer UI?
- Could cache state be masking a recent font or configuration change?
Equivalent guides by product
- Web SDK
- Document Engine
- DWS Viewer API