Burn Japanese, Chinese or Arabic captions: what Sume documents

Sume's caption docs document burned captions for Latin text and Korean Hangul, and nothing for Japanese, Chinese, or Arabic. That is not proof they fail, but it means Sume has not promised them, so test one short clip before you commit a campaign. For those scripts on a platform that accepts caption files, a sidecar file you make yourself avoids the font question.

This post reads the Video captions page of docs.sume.com and YouTube's subtitle and caption file formats page, both read on 2026-10-02.

What fonts does Sume's caption renderer document?

The docs name two families of faces. slam, punch, and tiktok-green draw in Latin display faces with no Hangul glyphs. The Hangul identities (black-outline, weight-shift, highlight, pill-karaoke, clip-wipe, editorial-emphasis) and the font options are Hangul faces, all under the SIL Open Font License 1.1.

The font field is for Hangul faces and only works with Hangul styles. Any name outside the documented list is rejected, not substituted.

Does the language field fix it?

No. The docs are explicit that language is a speech-to-text hint, such as ko or en, and that it "never selects the style or the font". Setting language: "ja" helps recognition of Japanese speech; it does not add a Japanese face to the render.

The docs describe what happens when Hangul text meets a Latin style: the request is rejected with 400 (caption_hangul_text_latin_style), because a video full of tofu boxes costs the same as a good one. The docs state this only for Hangul, so do not assume another script is protected the same way. A bad render would still bill like a good one.

How should you test a script Sume does not document?

Cut a 5 to 10 second sample, run one caption job, and look at every frame with text. Check for empty boxes in place of characters, wrong line breaks, missing diacritics, and in right-to-left text, reversed word order. One job costs $0.20 for video up to 60 seconds, which is cheaper than finding the problem after a batch.

If the sample is clean, you have evidence for that script and style on that day. If it is not, do not retry with other styles hoping for a fix; the docs list no face for that script.

What is the sidecar alternative?

YouTube accepts caption files in formats such as SubRip (.srt), WebVTT (.vtt), and TTML (.ttml), as plain UTF-8 text. SubRip carries no styling; WebVTT allows positioning and limited styling; TTML supports full styling and positioning. A sidecar file lets the viewer's player choose the font, which sidesteps the glyph question.

Sume's caption docs describe burned captions from a job and say SRT uploads are unsupported as input; they describe no caption file export. So for a sidecar you need your own tool, and Sume can still handle the burned version for markets where the font is documented.