Documentation
Languages and scripts
A template can hold text in any language, and a document is never refused because of the script its text is written in. Not every output prints every script correctly yet, though, so this page says what each one does — measured by rendering real text, not assumed — and every file that has one of these problems carries a warning that says so.
How it was measured: the same sentences were rendered to PDF exactly as the product produces it, the HTML output was opened in Chrome, and the Word file was opened in LibreOffice. The order in which the words actually appear on the page was read from each output, and checked against the order a reader of that language needs. Right-to-left results have not yet been reviewed by a native reader.
What each output does
| Writing system | HTML | Word | |
|---|---|---|---|
| Latin, Cyrillic, Greek | Correct | Correct | Correct |
| Arabic, Hebrew | Letters print and join, but a phrase of two or more words prints in the wrong order | Word order correct; paragraph direction is left to right (see below) | Word order correct; paragraph direction is left to right (see below) |
| Chinese, Japanese, Korean | No font: prints as empty boxes | Drawn with the reader’s own fonts; a wrapping paragraph can run into what follows it | Drawn with the reader’s own fonts |
| Hindi (Devanagari), Thai | No font: prints as empty boxes | Not checked yet | Not checked yet |
Paragraph direction. Every output lays paragraphs out left to right, and there is no right-to-left paragraph setting yet. The words of an Arabic or Hebrew sentence still read in the right order in HTML and Word, but punctuation or digits at the start or end of the sentence, and a Latin name inside it, end up on the wrong side.
Fonts in PDF. A PDF can only use the fonts we embed. Arabic prints only in a sans-serif font, and Hebrew only in a sans-serif font or Times New Roman; in any other font they print as empty boxes. None of the embedded fonts has Chinese, Japanese, Korean, Devanagari or Thai characters.
Tables in PDF. A table cell draws each of its lines as one piece. An Arabic or Hebrew cell prints correctly as long as it holds no Latin letters or digits; a cell that starts with Latin text prints its Arabic or Hebrew letters backwards, and digits in an Arabic or Hebrew cell come out reversed. A cell given its own font that lacks Arabic or Hebrew prints them as empty boxes, and that case is not yet warned.
Japanese in HTML. The HTML page is marked as English, so a browser may draw Japanese kanji from a Chinese font, which gives some characters their Chinese shapes.
The warnings
A preview or download that has one of these problems says so. Through the API the same signals
arrive as codes in the X-Ristmark-Render-Warnings response header (see API). None of
them refuses a render, strict or not.
| Code | Output | What happened |
|---|---|---|
glyphs-missing |
Characters no embedded font has printed as empty boxes | |
rtl-word-order |
Arabic or Hebrew words, and punctuation beside them, printed in the wrong order | |
rtl-paragraph-direction |
HTML, Word | An Arabic or Hebrew paragraph starts or ends with punctuation or digits, or contains a Latin phrase, which lands on the wrong side |
cjk-text-overflow |
HTML | A wrapping Chinese, Japanese or Korean paragraph is wider than the space the layout reserved and runs into what follows |
japanese-letterforms |
HTML | Japanese kanji may have been drawn from a Chinese font |
If your documents need Arabic, Hebrew or East Asian text today, use the output the table marks correct for it, and check the file before sending it.