I’m trying OnlyOffice v9.2.1. When I type a long line, the line breaks automatically continuing to the next line. However, the break point is not appropriate. It leaves a wide space at the end of the first line. For example…
Marix
20 February 2026 15:23
2
Hello, @nibbana !
1 Like
Marix
27 February 2026 12:28
5
Hello, @nibbana
2 Likes
Marix
7 August 2026 15:31
7
Hello, @moorisu
Thank you for sharing your feedback and for your interest in ONLYOFFICE. We understand how important correct Japanese line breaking is for everyday and professional use.
We’ve added your feedback and the affected version to the existing bug in our internal tracker.
We’ll keep you updated in this thread as soon as we have any news.
1 Like
Hi, @Marix , thank you for your response. Looking forward to the fix!
By the way, I accidentally deleted my original post. Sorry about that. I put the original post below for future reference.
Hi, I’m another Japanese user. I recently discovered ONLYOFFICE and found it to be a promising office suite for Linux. However, while trying it out, I encountered the same issue in version 9.4.0.129.
This is a major issue for Japanese users, as it makes ONLYOFFICE difficult to use for professional, academic, or other serious documents. Apart from this issue, I would be very happy to use ONLYOFFICE as my main office suite. I hope fixing it can be given high priority.
2 Likes
Hi, @moorisu ! Thank you for restoring the details.
1 Like
Hi @Nurullo and @Marix ,
After some investigation, I found that this behavior is caused by a few functions in sdkjs. I opened a PR with a fix:
master ← zeptometer:fix/japanese-line-breaking
opened 09:06AM - 10 Aug 26 UTC
## Summary
Fix Japanese line breaking between ordinary Kana characters and af… ter Japanese punctuation.
Related forum report and internal issue 80386: https://community.onlyoffice.com/t/line-break-in-japanese/18457
### Case 1: Break occurs too early before a Hiragana sequence
```text
...途中で改行されると思
いますが、...
```
### Case 2: Break occurs too early in a sequence of Japanese text, Japanese punctuation, and Latin text
```text
...日本
語、OnlyOffice...
```
### Case 3: Japanese punctuation begins a line
```text
...しかし
、OnlyOfficeは...
```
<img width="400" alt="issue" src="https://github.com/user-attachments/assets/217bde65-d5e1-41bd-8cf9-b61188a55243" />
These cases expose two related problems: `isEastAsianPunctuation()` classified non-punctuation characters as punctuation, and the line-break predicates used that classification to suppress break opportunities on both sides of a character. Cases 1 and 3 arose from the interaction of both problems, while Case 2 shows that the second problem also affects correctly classified punctuation. This patch removes `isEastAsianPunctuation()` from the line-break predicates. Narrowing the retained helper's range is a secondary classification fix.
## Root cause
These behaviors are caused by the interaction of two parts of the line-breaking code:
1. [`isEastAsianPunctuation()`](https://github.com/ONLYOFFICE/sdkjs/blob/72b0421c0bbf9d01eed9cf14834ae47eb2df1b50/common/editorscommon.js#L11900-L11903) classified the entire `U+3000–U+4DB5` range as punctuation, including ordinary Hiragana and Katakana.
2. [`CRunText.IsSpaceBefore()`](https://github.com/ONLYOFFICE/sdkjs/blob/72b0421c0bbf9d01eed9cf14834ae47eb2df1b50/word/Editor/Paragraph/RunContent/Text.js#L484-L490) and [`private_IsSpaceAfter()`](https://github.com/ONLYOFFICE/sdkjs/blob/72b0421c0bbf9d01eed9cf14834ae47eb2df1b50/word/Editor/Paragraph/RunContent/Text.js#L571-L581) suppressed break opportunities for every character classified that way.
### Overly broad punctuation classification
The original range covered several Unicode blocks:
```text
U+3000–U+303F CJK Symbols and Punctuation
U+3040–U+309F Hiragana
U+30A0–U+30FF Katakana
...
U+3400–U+4DB5 CJK Unified Ideographs Extension A
```
For example, `い` (`U+3044`) was reported as both East Asian text and East Asian punctuation.
### Punctuation excluded in both directions
The relevant predicates were effectively:
```js
// IsSpaceBefore()
isEastAsianScript(value)
&& !isHangul(value)
&& !isEastAsianPunctuation(value)
// private_IsSpaceAfter()
isEastAsianScript(value)
&& CanBeAtEndOfLine()
&& !isHangul(value)
&& !isEastAsianPunctuation(value)
```
`IsSpaceBefore()` and `IsSpaceAfter()` are complementary. A boundary at `O|い` can be exposed by `い.IsSpaceBefore()`, while a boundary at `、|O` must be exposed by `、.IsSpaceAfter()` because `O` is not East Asian text. Excluding punctuation from both predicates therefore removes valid boundaries as well as invalid ones.
### How this produces each case
#### Case 1: Hiragana sequence
Because ordinary Hiragana was classified as punctuation, both predicates returned false inside `いますが`. The sequence was accumulated like a Western word, so layout could move the whole sequence to the next line.
#### Case 2: Japanese text, Japanese punctuation, and Latin text
At `、|O`, `、.IsSpaceAfter()` returned false because `、` was punctuation, while `O.IsSpaceBefore()` returned false because `O` is Latin. With no break opportunity between them, layout could fall back to an earlier Japanese boundary and leave unnecessary space at the end of the line.
#### Case 3: Punctuation at the beginning of a line
When suppressed break opportunities made the text one long word-like segment, [`FindLineBreakInLongWord()`](https://github.com/ONLYOFFICE/sdkjs/blob/72b0421c0bbf9d01eed9cf14834ae47eb2df1b50/word/Editor/Paragraph_Recalculate.js#L2733-L2773) selected a split position by width without consulting `CanBeAtBeginOfLine()` or `CanBeAtEndOfLine()`. It could therefore split immediately before `、`, even though the punctuation table correctly marks `、` as unable to begin a line.
### Why this fix works
Punctuation restrictions are directional. The normal line-breaking path already uses [`CanBeAtBeginOfLine()`](https://github.com/ONLYOFFICE/sdkjs/blob/72b0421c0bbf9d01eed9cf14834ae47eb2df1b50/word/Editor/Paragraph/RunContent/Text.js#L582-L588) to prevent closing punctuation from beginning a line and [`CanBeAtEndOfLine()`](https://github.com/ONLYOFFICE/sdkjs/blob/72b0421c0bbf9d01eed9cf14834ae47eb2df1b50/word/Editor/Paragraph/RunContent/Text.js#L589-L595) to prevent opening punctuation from ending one.
Removing `isEastAsianPunctuation()` from the two predicates restores normal East Asian break opportunities. The directional checks still reject a break before `、` or after `「`, while a valid break after `、` can be recorded. It also prevents these Japanese sequences from unnecessarily reaching the long-word fallback.
The Hangul and punctuation exclusions were introduced together by [`Fix bug #78485`](https://github.com/ONLYOFFICE/sdkjs/commit/4ad64818d53b662c4d995fb37927198dd7ba92d0), whose purpose was to avoid breaking Korean words. This patch retains the `!isHangul(...)` condition and removes only the unrelated punctuation exclusion.
The exported `isEastAsianPunctuation()` function is retained for compatibility and its range is narrowed as a secondary classification fix. The line-breaking fix itself no longer depends on it.
## Changes
- Stop using `isEastAsianPunctuation()` to suppress break opportunities in `IsSpaceBefore()` and `private_IsSpaceAfter()`.
- Continue using `CanBeAtBeginOfLine()` and `CanBeAtEndOfLine()` for directional punctuation restrictions in the normal line-breaking path.
- Preserve the existing Hangul exclusion, so Korean word-breaking behavior is unchanged.
- Retain the exported `isEastAsianPunctuation()` symbol for compatibility, but narrow its range from `U+3000–U+4DB5` to `U+3000–U+303F` as a secondary classification fix.
## Testing
Static checks:
- [x] `node --check common/editorscommon.js`
- [x] `node --check word/Editor/Paragraph/RunContent/Text.js`
- [x] `git diff --check`
Manual Document Editor checks:
- [x] Confirm that `改行されると思いますが` can wrap inside the Hiragana sequence.
- [x] Confirm that `日本語、OnlyOfficeは` can wrap after `、`.
- [x] Confirm that closing punctuation such as `、。）」】` does not begin a line.
- [x] Confirm that opening punctuation such as `「『（【` does not end a line.
- [ ] Confirm that the existing Korean behavior is unchanged.
Before fix:
<img width="400" alt="original_behavior" src="https://github.com/user-attachments/assets/29dc7555-5611-4d86-9529-f2b672bf9c2d" />
After fix:
<img width="400" alt="fixed_behavior" src="https://github.com/user-attachments/assets/b0cf5281-68a5-459b-a781-43eab64799d0" />
## Questions for maintainers
### Test coverage
I could not identify an active in-tree test suite for Word paragraph line breaking. Where should an external contributor add regression coverage for the following cases?
1. Breaking inside a Hiragana sequence: `改行されると思いますが`
2. Breaking after Japanese punctuation before a Latin word: `日本語、OnlyOfficeは`
3. A control confirming that closing punctuation cannot begin a line and opening punctuation cannot end one
4. A control confirming that Hangul behavior remains unchanged
### Compatibility
After this change, `isEastAsianPunctuation()` has no remaining in-tree callers. This patch retains it because it is exported through the `AscCommon` namespace and may be used by downstream or separately versioned code.
Is this function considered part of the compatibility surface, or would you prefer it to be removed?
At least in my testing, it seems to work correctly for the cases discussed in this thread.
Hope this helps!
2 Likes
Marix
18 August 2026 15:22
11
Hi, @moorisu
Thank you very much for investigating this issue and for preparing a pull request with a fix. We really appreciate your detailed analysis and contribution.
Thank you as well for sharing it here on the forum with us and other users — we believe this information will be very helpful to everyone experiencing the same behavior.
