https://bugs.documentfoundation.org/show_bug.cgi?id=174224
Bug ID: 174224
Summary: Writer — Asian double-line text with brackets renders
as overlapping, illegible glyphs
Product: LibreOffice
Version: 26.8.0.3 release
Hardware: ARM
OS: macOS (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
Description:
# Bug report: Writer — Asian double-line text with brackets renders as
overlapping, illegible glyphs
## Bugzilla fields
**Product:** LibreOffice
**Component:** Writer
**Version:** 26.8.0.3
**Operating system:** macOS (architecture to be confirmed from tested
installation)
**Severity:** normal
**Reproducibility:** Always, in the tested environment
**Summary:**
Writer: Asian double-line text with start/end brackets renders as overlapping,
illegible glyphs
---
## Description
LibreOffice Writer supports Asian double-line text formatting (Japanese
warichū, 割注) through the ODF property `style:text-combine="lines"`.
Without brackets, the formatting produces two readable lines of reduced-size
text.
However, when the same formatting includes start and end brackets using
`style:text-combine-start-char` and `style:text-combine-end-char`, the
annotation renders as an overlapping, illegible cluster of glyphs.
The problem occurs with native ODF formatting and does not require any
third-party extension.
### Steps to Reproduce
1. Open the attached file `u1_text_combine_brackets_collapse.odt` in
LibreOffice Writer 26.8.0.3.
2. Locate the paragraph labelled **CONTROL bare combine**.
3. Observe that the annotation following `本文` is displayed as two readable
lines of reduced-size Japanese text.
4. Locate the paragraph labelled **FAIL with brackets**.
5. Observe that the same annotation, formatted with the start/end brackets `(`
and `)`, renders as an overlapping, illegible cluster.
6. Optionally export the document to PDF. The same rendering defect is present
in the exported PDF.
### Actual Results
The double-line annotation with start/end brackets is unreadable because its
glyphs overlap.
The equivalent annotation without brackets renders correctly.
The problem occurs both in Writer's document display and in PDF export.
### Expected Results
The annotation should remain legible as two lines of reduced-size Japanese
text, with the specified brackets displayed around the annotation.
Adding start/end brackets should not cause the annotation characters to overlap
or collapse.
### Reproducibility
Always, with the attached reproducer on LibreOffice 26.8.0.3 for macOS.
### User Profile Reset
Not performed.
### Additional Information
**LibreOffice version:** 26.8.0.3
**Build ID:** `bce0998afefdbc355585ca324285661a2170ba77`
The attached ODT uses native ODF character styles, including:
- `style:family="text"`
- `style:text-combine="lines"`
- `style:text-combine-start-char="("`
- `style:text-combine-end-char=")"`
The document was constructed using native ODF formatting, independently of any
third-party extension.
The defect was also reproduced by converting the ODT to PDF using LibreOffice's
headless `soffice --convert-to pdf` command, without a third-party extension
loaded.
The attached file includes a control case without brackets and a failing case
with brackets, allowing direct comparison.
**Relevant specification:** W3C *Requirements for Japanese Text Layout*
(JLREQ), section on warichū (inline cutting notes).
---
## Attachments
**1. Minimal ODT reproducer — essential**
`u1_text_combine_brackets_collapse.odt`
Contains both the working control case and the failing bracketed annotation.
**2. Screenshot — recommended**
`u1_text_combine_brackets_collapse.pdf.png`
Shows the difference between the readable control and the overlapping bracketed
annotation.
**3. PDF export — supplementary**
`u1_text_combine_brackets_collapse.pdf`
Demonstrates that the defect also occurs in exported output.
---
## Notes before filing
Confirm the tested macOS architecture and enter it accurately in Bugzilla.
Perform one final duplicate search using terms such as “double lines”, “Asian
layout”, “text combine”, and “brackets”.
If an existing report describes the same defect, add the reproducer there
instead of opening a duplicate.
Do not include the suspected internal cause in the initial report. The
source-code investigation can be supplied separately if requested by a
maintainer.
This report concerns only the bracket-rendering defect. The separate kinsoku
line-breaking issues should be reported independently.
Steps to Reproduce:
1. Open the attached ODT file in LibreOffice Writer 26.8.0.3.
2. Locate the paragraph labelled "CONTROL bare combine".
3. Observe the annotation following 本文: it displays as two readable lines of
reduced-size Japanese text.
4. Locate the paragraph labelled "FAIL with brackets".
5. Observe the same annotation with the start/end brackets ( and ).
6. Export the document to PDF. The rendering defect is also present in the PDF.
Actual Results:
The double-line annotation with start/end brackets renders as an overlapping,
illegible cluster of glyphs.
The equivalent annotation without brackets renders correctly as two lines of
reduced-size Japanese text.
The problem occurs both in Writer's document display and in PDF export.
Expected Results:
The annotation should remain legible as two lines of reduced-size Japanese
text, with the specified brackets displayed around it.
Adding start/end brackets should not cause the annotation characters to overlap
or collapse.
Reproducible: Always
User Profile Reset: No
Additional Info:
LibreOffice version: 26.8.0.3
Build ID: bce0998afefdbc355585ca324285661a2170ba77
Operating system: macOS
This issue concerns Asian double-line text formatting (Japanese warichū, 割注).
The attached ODT was constructed using native ODF formatting, independently of
any third-party extension.
The relevant ODF properties are:
style:family="text"
style:text-combine="lines"
style:text-combine-start-char="("
style:text-combine-end-char=")"
The defect was also reproduced using headless LibreOffice PDF conversion
(soffice --convert-to pdf), without any third-party extension loaded.
The attached ODT contains both a working control case without brackets and a
failing case with brackets.
Related specification:
W3C Requirements for Japanese Text Layout (JLREQ), section 3.3.5 (Warichū).
--
You are receiving this mail because:
You are the assignee for the bug.