Start a conversation

Greek/Special Characters Missing in Generated PDFs (Visualforce PDF Font Limitation)

Contents

Overview

Generated PDFs may display Greek/special characters as blank or missing when the PDF output is produced through a Salesforce Visualforce PDF template that uses a font with insufficient Greek glyph support/embedding (commonly Verdana). Although this can look like a CloudSense CLM/Contract Generation issue (including scenarios observed on CloudSense package version R36), the root cause is a Salesforce Visualforce PDF renderer font limitation.

The clause text is stored correctly as Unicode, but the PDF renderer may drop glyphs when it cannot reliably embed/map the selected font. Mitigation is to force a Greek-capable font in the Visualforce template (quick fix) or embed a Unicode-capable TTF as a Static Resource and apply it via @font-face (best-practice long-term fix).

Solution

Symptom / Error Identification

You may be affected if:

  • Generated PDFs display Greek/special characters as blank/missing (for example: “Greek characters … appear missing/blank”).
  • The issue is font-dependent (e.g., fails with Verdana but works with Arial).
  • The issue is reproducible for multiple users and only certain clauses/templates.

Context (What’s Actually Happening)

  • Clause content is stored correctly in Salesforce as Unicode.
  • When the agreement/document is rendered to PDF via a Salesforce Visualforce PDF template, Salesforce’s PDF renderer has limited font support/embedding.
  • If the renderer cannot reliably embed/map a font (commonly Verdana for Greek), Greek glyphs are dropped, resulting in blank output.
  • Fonts with Greek glyph coverage (commonly Arial) render correctly.

Ownership/Responsibility: This behavior aligns with a limitation in Salesforce’s Visualforce PDF rendering (font embedding/mapping), not a CloudSense package defect.

Investigation / Troubleshooting Method

  1. Reproduce the behavior
    • In your Salesforce/CloudSense process, open a representative record (e.g., a Product Basket or equivalent document-generation entry point).
    • Click Generate Document.
    • Open the generated file from Files (or your document repository UI).
  2. Isolate by font
    • Identify the font specified by your template/CSS and/or clause rich text (often inline style="font-family: Verdana" from rich text).
    • Temporarily switch the output font to Arial to confirm whether the issue is font/glyph coverage related.
  3. Confirm the rendering path
    • Verify which Visualforce page is used for the PDF output (the Visualforce template backing your Document Template).

Resolution (Robust / Quick Mitigation): Force a Greek-capable Font in the VF PDF Output

Update the Visualforce PDF template page (your custom agreement/document PDF Visualforce page) and add a final CSS override that forces a Unicode/Greek-capable font.

Important placement requirement

  • Place this CSS after all <apex:stylesheet .../> includes (including the template’s main CSS static resource reference), so it overrides earlier styles.

Example

<head>
  <meta charset="UTF-8"/>
  <style type="text/css">
    /* Force Unicode-capable font for PDF output (overrides inline Verdana) */
    body, body * {
      font-family: "Arial Unicode MS", Arial, sans-serif !important;
    }
  </style>
</head>

Why !important is used

  • Clause rich text can contain inline styling such as font-family: Verdana.
  • !important ensures the PDF output uses the Greek-capable font even when inline styles exist.

Best-Practice Long-Term Fix: Embed a Unicode-capable TTF and Enforce It

For maximum reliability across languages (Greek and other non-Latin scripts):

  1. Upload a Unicode-capable TTF font (e.g., Noto Sans) as a Salesforce Static Resource (e.g., <unicode_font_resource>).
  2. Reference it in the Visualforce PDF template via @font-face.
  3. Force that font across the PDF content (similar to the quick mitigation, but pointing to your embedded font).

This reduces dependence on which fonts Salesforce’s PDF renderer happens to embed/map successfully.

Illustrative pattern (adjust resource and file names to match your org)

<style type="text/css">
  @font-face {
    font-family: 'MyUnicodeFont';
    src: url('{!URLFOR($Resource.unicode_font_resource, 'YourFontFile.ttf')}');
  }

  body, body * {
    font-family: 'MyUnicodeFont', sans-serif !important;
  }
</style>

Validation Steps

  1. Regenerate the document (do not rely on previously generated PDFs).
  2. Open the new PDF and confirm:
    • Greek characters display correctly in the affected clauses.
    • Mixed content (Greek + Latin + punctuation) renders as expected.
  3. Re-test a clause that previously failed specifically under Verdana styling to confirm the override is effective.

Frequently Asked Questions

1. How do I know this is the same issue?
If the generated PDF shows Greek/special characters as blank/missing (for example: “characters appear missing/blank”) and switching the font from Verdana to Arial makes the text appear, it matches this issue pattern.
2. Is this a CloudSense bug?
This behavior is consistent with a Salesforce Visualforce PDF renderer limitation (font embedding/mapping). The text is stored correctly as Unicode, but glyphs can be dropped when the renderer cannot reliably embed/map the selected font.
3. Where should the CSS override be added in the Visualforce template?
Add it in the Visualforce PDF page after all <apex:stylesheet .../> includes so it overrides template/static resource CSS. Use !important to override inline Verdana coming from clause rich text.
4. Why does Arial work but Verdana fails?
Arial typically includes Greek glyph coverage and is more reliably mapped/embedded by Salesforce’s PDF renderer. Verdana may not be reliably embedded/mapped for Greek in the PDF renderer, causing glyphs to be dropped.
5. What if the problem persists after forcing Arial/Arial Unicode MS?
Use the long-term approach: embed a Unicode-capable TTF (e.g., Noto Sans) as a Static Resource via @font-face and force that font in the Visualforce PDF template. Then regenerate and revalidate using a newly generated PDF.
Choose files or drag and drop files
Was this article helpful?
Yes
No
  1. Matej Storga

  2. Posted

Comments