A translated Japanese paragraph can fit the source page and still look wrong: a closing bracket lands at the start of a line, a quotation mark gets stranded, or uneven spacing makes a justified block look stretched. Chinese text can show similar problems, even when the translation itself is accurate. The cause often sits in the interaction between line-breaking rules and the layout engine, not in the words alone.
CJK line breaking is the process of deciding where Chinese, Japanese, and Korean text may wrap onto a new line. For translated documents, that decision affects punctuation, spacing, page flow, and readability. A translation can preserve every heading and table and still need layout review because the target script follows different conventions from the source.
This guide explains how those rules work, how justification differs from English text, and what localization teams should inspect before delivery. It focuses on Chinese and Japanese conventions covered by the sources below. Korean text also uses CJK characters, but its spacing and line-breaking behavior shouldn’t be assumed to match Chinese or Japanese.
What CJK line breaking means in a translated document¶
A line break is the point where text moves from one line to the next. English readers often expect a break between words, where a space provides a visible boundary. Chinese and Japanese running text don’t normally use spaces to mark word boundaries, so a typesetting system needs other cues to decide where a line can end.
Unicode UAX #14 describes a line-breaking algorithm that identifies suitable break opportunities. The algorithm doesn’t decide the final line endings by itself. Higher-level software selects actual positions using the available line width and display size, as the Unicode Line Breaking Algorithm explains.
That distinction matters in a translated file. The Unicode rules can permit a break, but a word processor or publishing application still has to choose which permitted break fits the line. The application also needs to know the page or text-box width, font metrics, and any language-specific settings.
UAX #14 distinguishes mandatory breaks, direct break opportunities, indirect opportunities that require intervening spaces, and prohibited breaks. Those categories give software a framework, not a promise that every application will make identical choices. The Unicode specification also allows tailoring where character properties are informative or local preferences matter.
In East Asian line breaking, a system can generally break between characters unless a rule prohibits the break. That broad approach differs from English word-based wrapping, but it doesn’t mean every character boundary is safe. Punctuation and other character combinations create constraints, and different writing systems can have different expectations.
The practical goal is not to force every line to end at the same character count. The goal is to let the application fill the available measure while respecting the conventions of the target language. A readable line may be slightly shorter than the line above it. A mechanically full line can still look wrong if it strands punctuation or spreads spacing unevenly.
A useful distinction is between a text rule and a layout decision. A text rule says that a break is allowed or forbidden at a particular point. A layout decision chooses among allowed points so the text fits the current line and page. Teams that treat those as one setting can spend time changing punctuation or manually inserting line breaks when the underlying issue is actually the target application’s configuration.
The Unicode Consortium says, “The selection of actual line break positions from the set of break opportunities is not covered by the Unicode Line Breaking Algorithm, but is in the domain of higher level software with knowledge of the available width and the display size of the text.” Read UAX #14.
In plain terms, the Unicode rules define where the layout engine may break, but the application chooses where it will break. A team reviewing a translated DOCX or PDF needs to inspect the file in the application that will render it, not just check that the text contains the right characters.
How punctuation and character width affect line endings¶
CJK punctuation rules protect the visual relationship between marks and the text around them. A closing punctuation mark generally shouldn’t begin a new line after the content it closes has stayed on the previous line. An opening mark, in turn, shouldn’t be left behind at the end of the previous line when its quoted or bracketed content starts below.
Japanese Kinsoku Shori is the name for rules governing which characters may appear at line beginnings or endings and which characters shouldn’t be separated across lines. Microsoft Learn describes Kinsoku Shori as rules specified in JIS X 4051, and explains that punctuation placement is constrained in many writing systems. The same guidance notes that an opening quotation mark shouldn’t be split from the first word of its quotation (Microsoft Learn: line and word breaking).
Unicode also supplies character classes that support those decisions. For example, the CL class includes closing punctuation, and UAX #14’s class description prohibits a line break before characters in that class. That rule is one basis for preventing a closing mark from appearing at a line start (UAX #14).
Character width adds another layer. Unicode UAX #11 assigns the East_Asian_Width property one of six default values: Ambiguous, Fullwidth, Halfwidth, Narrow, Wide, or Neutral. The specification’s live page identifies itself as Unicode 18.0.0, Revision 46; values resolve to narrow or wide depending on the context of a particular operation (UAX #11).
Wide characters often behave like ideographs for layout in East Asian contexts. Narrow characters tend to remain grouped in runs, and some may be rotated in vertical text. But East Asian Width is an input to layout, not a complete layout recipe. UAX #11 explicitly leaves font design and complete line-layout rules to other properties and implementation choices.
That limitation becomes visible in mixed-script documents. A Japanese paragraph may contain Latin product names, Arabic numerals, dates, or a URL. Those runs don’t necessarily occupy the same width as surrounding ideographs, and the rules for wrapping them may differ. A line that looks balanced in a monolingual paragraph can become crowded when a long Latin token appears near the margin.
A localization team should inspect the actual characters in a problem line before adjusting the whole paragraph. Ask whether the apparent gap comes from a full-width character, a narrow character run, punctuation compression, or the width of a Latin sequence. Changing paragraph spacing before identifying the cause can make adjacent lines less consistent.
The W3C Requirements for Chinese Text Layout documents Chinese composition requirements and maps layout issues to standards such as Unicode, with the aim of encouraging correct implementation. The document’s glossary defines punctuation compression as adjusting excess space at line beginnings, line endings, or between adjacent punctuation marks. Compression can help a line fit without adding arbitrary gaps between characters.
The key review question is not simply, “Does every line reach the margin?” Check whether the line ends preserve the intended relationship between punctuation and text, and whether width adjustments look consistent across the paragraph. A page can be technically full and typographically awkward at the same time.
How CJK text justification works¶
Justification adjusts spacing so a line fits between its margins. In English, the most familiar approach expands spaces between words. Chinese and Japanese running text don’t normally have those word spaces, so a layout engine needs other places to distribute adjustments.
Microsoft distinguishes inter-word or inter-cluster justification from inter-ideograph justification. Inter-ideograph justification can add spacing between CJK ideographs; the described strategy doesn’t add those spaces between Latin-script characters (Microsoft Learn: text justification).
Japanese text can also use adjustments around punctuation, at script-change boundaries, and between characters. Those options let the engine distribute space in a way that suits the script instead of inserting English-style gaps where no word boundary exists.
Microsoft Learn explains, “For example, even though the Japanese writing system doesn’t use spaces between words, spacing can be adjusted around punctuation, script-change boundaries, and between characters.” Read the text justification guidance.
The practical takeaway is that CJK justification isn’t a single command to “stretch the text.” The application needs an appropriate strategy for the script and paragraph. A paragraph containing Chinese characters, Japanese punctuation, and Latin text may need more than one spacing behavior within the same line.
A simple review table helps separate the problem from the setting:
| What you see | Likely mechanism | What to inspect |
|---|---|---|
| Large gaps between Latin letters | Inter-character expansion applied to the wrong script run | Justification behavior at script boundaries |
| Uneven spacing around Japanese punctuation | Punctuation adjustment or compression rules | Line edges and adjacent punctuation |
| Closing mark at the start of a line | Prohibited-break rule not applied, or an application-specific interpretation | Kinsoku settings and target application |
| Last line stretched across the paragraph | Final-line alignment behavior | Paragraph alignment and last-line handling |
| Lines appear crowded despite correct wrapping | Font metrics or width differences | Font availability, character widths, and text-box measure |
A justified paragraph’s final line often shouldn’t be stretched to the full measure. Microsoft Learn says, “The last line of a justified block of text might use left or right alignment rather than using significant amounts of whitespace to justify the line.” That choice keeps the last line from looking like a row of scattered characters. The exact result depends on the layout application and paragraph settings.
Microsoft Learn describes the final-line option in its text justification guidance.
For a document reviewer, the point is to compare the final line with the rest of the paragraph rather than assume full justification should apply uniformly. A short final line may be correct. An unusually stretched final line may indicate that the paragraph’s last-line alignment or justification setting needs attention.
Word provides document-level East Asian line-break controls. Microsoft documents a FarEastLineBreakLevel setting and notes that Word ignores the setting when FarEastLineBreakControl is false (Microsoft VBA documentation). A setting can exist in a file without affecting output if its controlling feature is off.
Application behavior also needs testing. Microsoft’s published Office implementation note identifies differences between the cited standard’s scope and Word’s behavior. The note says Word’s overflowPunct behavior can override kinsoku behavior when both apply to the same character (Microsoft Office implementation note). A document that looks correct in one processor may therefore need another check in the processor used by the recipient.
Why translated CJK documents overflow or reflow¶
Translated text reflows because a translation changes the text that the layout engine has to fit. Even when the source and target communicate the same meaning, their characters, punctuation, and line-break opportunities differ. A translated paragraph can need more or less space, and its line endings can move as a result.
The layout engine doesn’t merely count characters. It considers the width of each character or run, available line width, permitted break opportunities, and the rules applied to punctuation. East Asian Width helps describe character behavior, but Unicode notes that the property alone doesn’t prescribe complete line layout (UAX #11). Font metrics and application decisions also affect the result.
A fixed-width text box makes those differences easier to notice. If a translated line needs more room, the engine may move a word or character sequence down, change line endings throughout the paragraph, or push later content to another page. A small change near the top of a page can shift a table, heading, or footer below it.
Mixed-script text creates its own edge cases. A Japanese sentence may include a Latin abbreviation with no convenient break point. A Chinese paragraph may contain numbers and punctuation that don’t occupy space like nearby ideographs. A line-break rule can be correct for the surrounding CJK text yet still leave a narrow run too close to the margin.
PDF and Word files also present different review conditions. A Word document can reflow when opened with another font or application. A PDF normally fixes page appearance, but a translation prepared from a PDF may have to be reconstructed into editable text before the target text can be laid out. In either case, checking only the extracted text won’t reveal every spacing or line-ending issue.
Consider a translated Japanese heading that ends with a closing bracket near the right edge. If the paragraph width changes slightly, the bracket may move to the next line unless the layout engine applies the relevant prohibition or a suitable adjustment. Adding a manual line break might fix that page view, but the break can become awkward if the document later changes font or page size.
A better diagnostic sequence starts with the visible symptom:
- Identify the first line where the layout diverges from the expected page.
- Inspect the characters at the line ending and the start of the next line.
- Check whether punctuation, a Latin run, or a width-sensitive character is involved.
- Confirm the paragraph’s alignment and East Asian line-break controls.
- Reopen the file in the target application and compare the rendered result.
That sequence helps teams avoid treating every overflow as a translation-length problem. A paragraph can have a reasonable length and still wrap poorly because the line-break settings don’t match the target script. Conversely, a correct kinsoku setting can’t make a text box large enough for a translated paragraph that genuinely needs more room.
The translated PDF layout verification guide gives a page-by-page review approach for checking the rendered result. For Word files, the guide to preserving Word styles during translation covers heading, table-of-contents, and layout checks that can help distinguish style changes from text reflow.
When to use CJK-specific line breaking and when not to¶
CJK-specific controls matter when the document contains Chinese or Japanese text and its line endings affect readability or presentation. A reader-facing report, manual, form, or polished business document needs punctuation to sit naturally and text to fill lines without conspicuous spacing. Applying English word-spacing assumptions to those paragraphs can produce gaps or awkward wraps.
A CJK-aware layout engine is also useful when a document mixes scripts. The engine can treat ideographs, punctuation, and Latin runs according to their character properties rather than applying one blunt spacing rule to the whole paragraph. The Microsoft guidance on line and word breaking explains why systems that don’t use spaces to mark word boundaries need different break handling.
Not every translated file needs manual typography work. A short internal reference with ragged-right alignment may remain easy to read even if the line endings differ from the source. Manual intervention becomes more important when the file is customer-facing, has narrow columns, contains dense punctuation, or must match a fixed page design.
Avoid adding manual line breaks as a first response. A forced break can hold a punctuation mark in place on one page but create a bad line when the font, page size, or text changes. Use manual breaks only when the document’s design calls for a deliberate line ending and the file’s future editing conditions are understood.
Avoid applying justification to every paragraph by default. Left alignment can be clearer than a block with irregular spacing, particularly when the final line is short or a paragraph contains several Latin runs. Justification is a layout choice, not a proof of professional quality.
A useful rule of thumb is to choose the least complicated treatment that preserves readability. Use the language-appropriate line-break behavior first. Add justification only when the document design calls for it. Reserve manual line-level intervention for cases where the intended design can’t be achieved through paragraph and application settings.
The W3C Chinese layout document provides a reference for Chinese composition issues, while Unicode UAX #14 and UAX #11 describe line-breaking and width properties. Those sources don’t replace review in the document’s destination application. Standards guide implementations; they don’t guarantee identical rendering across processors.
Teams working with legal or official files can also use the guide to translating legal documents without layout errors. That review should include the target language’s punctuation and line endings alongside the usual checks for names, dates, fields, and page structure.
Common CJK layout mistakes and a practical QA checklist¶
Many visible problems start with an assumption that a translated paragraph should keep the source’s exact line endings. Translation changes the text, and different scripts use different wrapping conventions. The source page can be a useful reference, but forcing the same break positions may damage the target-language rhythm.
Another common mistake is to treat each character as having the same width. East Asian Width distinguishes six default values in the live Unicode 18.0.0, Revision 46 specification, but width behavior also depends on context and implementation (UAX #11). A reviewer who judges a line only by its character count can miss why it overflows.
A third mistake is to assume a standard guarantees identical application behavior. Unicode defines break opportunities and character properties, while higher-level software makes fitting decisions. Microsoft’s Office note describes an implementation difference in how Word can handle overflow punctuation and kinsoku rules (implementation note). Teams should verify the actual output instead of inferring it from a standards label or file setting.
Use this checklist during review:
- Check punctuation at both line edges. Look for closing marks at line beginnings and opening quotation marks separated from the quoted text.
- Inspect mixed-script runs. Review Latin names, abbreviations, URLs, and numerals within Chinese or Japanese paragraphs.
- Review spacing, not just wrapping. Check that justification hasn’t inserted obvious gaps between Latin letters or made CJK spacing appear uneven.
- Look at the final line. Confirm that the paragraph’s last line isn’t stretched in a way that conflicts with the document’s design.
- Check the control and its parent setting. In Word, FarEastLineBreakLevel is ignored when FarEastLineBreakControl is false, according to the Microsoft VBA reference.
- Render in the recipient’s application. A document can use different line endings when another processor interprets its fonts and settings.
- Review the page after a correction. A local line-break fix can move content below it, so check the surrounding paragraph, table, and page break again.
The Unicode Consortium distinguishes break opportunities from final line-ending choices, and Microsoft documents application-specific behavior for East Asian punctuation. See UAX #14 and the Office implementation note.
The practical lesson is to review text, settings, and rendered output as one system. A line-break defect may come from a character rule, a paragraph setting, a font, or the software that displays the file. Fixing the right layer prevents the same problem from returning on the next page or in the next application.
FAQ¶
How do CJK line-breaking rules differ from English rules?¶
English text commonly wraps at spaces between words. Chinese and Japanese running text don’t normally use spaces to show word boundaries, so layout engines rely on character properties and language-specific rules to find suitable breaks. Unicode UAX #14 defines break opportunities, while the application chooses actual line endings using the available width.
How do I stop Japanese punctuation from appearing at the start of a line?¶
Use an application that applies Japanese Kinsoku Shori rules, then check the rendered document in the software that recipients will use. Kinsoku rules govern which characters may appear at line beginnings or endings, and application behavior can vary. Microsoft’s line-breaking guidance describes the rules and Unicode UAX #14 prohibits breaks before its CL closing-punctuation class.
How should Chinese and Japanese text be justified?¶
Use inter-ideograph spacing where appropriate, with adjustments around punctuation or script-change boundaries when the layout engine supports them. Don’t assume English-style word spacing applies to text that has no word spaces. Keep the final line aligned rather than stretching it with conspicuous gaps.
Why does translated CJK text overflow or reflow?¶
Translation changes the characters and line-break opportunities that the layout engine must fit into each line. Font metrics, character widths, punctuation rules, text-box width, and application behavior all affect the result. A paragraph can reflow even when its translation is accurate and its formatting appears unchanged.
What should localization teams check when reviewing CJK document layout?¶
Check punctuation at line starts and endings, mixed-script text, character-width behavior, justification, final-line alignment, and page flow. Review the file in the target application, since standards define useful rules but don’t guarantee that every processor will render a document identically.