Skip to main content

International text

Court communication is multilingual. The API renders international text two ways, depending on how the document is authored:

  • HTML documents use the embedded Noto fonts natively. Specify the family in CSS.
  • Drawn fields (template versions and blank-page documents) use a compact standard character set by default; enable Unicode mode for full script coverage.

Unicode mode​

Opt in per document: "unicode": true on a /v1/documents request, or "defaults": { "unicode": true } on a template version:

{
  "page": { "size": "letter" },
  "unicode": true,
  "fields": [
    { "type": "text", "content": "Ngày điều trần: 15 tháng 8, 2026", "x": 72, "y": 72, "width": 400, "height": 24 }
  ]
}

With Unicode mode on, drawn text and markdown render with embedded fonts covering Latin-extended, Greek, Cyrillic, and Vietnamese, plus CJK. The best-covering font is selected automatically per field. Code points that still cannot be rendered are reported with a UNICODE_MISSING_GLYPHS warning.

Without Unicode mode, characters outside the standard Latin character set are substituted with ? and reported as TEXT_SUBSTITUTED. The document never fails, but check the warnings when your data may contain non-Latin names.

Interactive form values are the exception. Values typed into or filled into interactive form fields (field, fill) use the standard character set even in Unicode mode; out-of-set characters there are substituted and reported. When full script fidelity matters, render the value as drawn text (or author the document in HTML) rather than as a form value.

Right-to-left text​

Set the paragraph base direction with typography.direction. It requires Unicode mode:

{
  "unicode": true,
  "fields": [
    { "type": "text", "content": "מספר תיק: 2026-CV-1042",
      "typography": { "direction": "rtl" },
      "x": 72, "y": 120, "width": 400, "height": 24 }
  ]
}
  • "rtl" reorders each line for display per the Unicode Bidirectional Algorithm, with bracket mirroring, and defaults alignment to right unless you request one.
  • "auto" lets the first strong character decide, useful when the same field renders English for one recipient and Hebrew for the next.
  • Mixed-direction content (Hebrew text containing case numbers or dates) renders correctly on one baseline.
  • Setting a direction without Unicode mode renders left-to-right and reports a DIRECTION_REQUIRES_UNICODE warning.

For Hebrew in HTML documents, use the "Noto Sans Hebrew" family with CSS direction: rtl (HTML fonts).

Practices​

  • Turn on Unicode mode for any template whose merge data may contain names or addresses in non-Latin scripts (the cost is a somewhat larger file).
  • Watch for TEXT_SUBSTITUTED and UNICODE_MISSING_GLYPHS warnings in your integration's logs; they are the signal that a recipient's name didn't render as written.
  • Test with real data from your case management system, not ASCII samples.