PPTX: a space is inserted between an a:buChar bullet and its text, flipping two wrap points

[developer0hye]

Summary

The output inserts a space between an a:buChar bullet glyph and the text that follows
it. PowerPoint inserts none — the text starts at the indent, and nothing separates it
from the bullet but the tab. The extra advance is enough to push the last syllable of a
bullet past the column width, so it changes where lines break.

Measured

tests/fixtures/pptx/office2pdf_introduction_ko.pptx, page 28, the four bullet columns.

marL and indent are identical on both sides — continuation lines start at x = 99.00pt
in both — so the indent model is right; only the bullet-to-text gap differs. GT emits
•람다, the output emits • 람다.

Two bullets re-wrap as a result:

GT	office2pdf
패키지 용량 제약 대응에 유리 on one line	…대응에 유 / 리
사용자 환경에 오피스 설치 요 / 구 없음	사용자 환경에 오피스 설치 / 요구 없음

Reproduction

cargo run --release -p office2pdf-cli -- \
    tests/fixtures/pptx/office2pdf_introduction_ko.pptx -o out.pdf

Page 28's bullets break one syllable earlier than a native PowerPoint export.

Expected

No space is inserted between an a:buChar glyph and its paragraph text; the gap comes
entirely from marL/indent.

Actual

A space is inserted, widening every bullet's first line and flipping two wrap points.

Found in the 2026-07-29 full-corpus visual audit at c1adfbd (native Office GT, 150 DPI, mutool-trace geometry).

Visual comparison

Compare

GT left, office2pdf right, 150 DPI, same page.

[developer0hye]

Investigating this, the mechanism is not a space — it is the tab.

prepend_fixed_text_list_marker_run (crates/office2pdf/src/render/typst_gen_lists.rs:1037) builds the marker run as:

format!("{marker_text}\t")

A tab, not a space. Nothing in the a:buChar path inserts a space character. (The one place a space is appended, normalize_fixed_text_ordered_grid_marker at :704, is the ordered-list grid path and does not run for bullets.)

So the extra advance comes from how that tab resolves, not from a stray character. That fits the measurement already in this issue: marL and indent agree with GT and continuation lines land at x = 99.00pt on both sides, so the indent model is right — what differs is the distance the tab covers between the bullet glyph and the first character.

That makes the fix a different shape from what the title suggests. "Remove the inserted space" has nothing to remove; the question is what the tab after an a:buChar should advance to. In PowerPoint it advances to the paragraph's indent stop, so the text starts exactly at the indent regardless of the bullet glyph's width. If the emitted tab instead advances by a default tab increment, the gap will vary with the bullet glyph and will not generally land on the indent.

Worth confirming before implementing: measure the x-origin of the first text glyph on a bulleted line in GT versus the output with mutool draw -F trace, and compare both against the declared indent. If GT's first glyph sits exactly at the indent and the output's sits further right by a varying amount, the tab-stop reading is confirmed and the fix is to make the marker cell consume exactly the hanging indent.

Not attempting a fix on that basis yet — the title's framing would lead someone to look for a character that is not there.

[developer0hye]

Refining my earlier comment with an extraction check, because it narrows where to look.

pdftotext -f 28 -l 28 on the current output puts the bullet and its text on separate lines:

14: •
16: 람다/함수 환경에 담일 바디

So the bullet is not inline with the text in the output at all — it occupies its own layout box. That is consistent with the grid path (write_fixed_text_ordered_marker_grid emits #grid(columns: (<hanging-indent>pt, 1fr))), not with the inline "{marker}\t" path I pointed at before.

If the grid path is the one taken here, then the gap between bullet and text is the grid column width — i.e. the hanging indent — and neither a literal space nor a tab advance is responsible. Two consequences:

• "Remove the inserted space" has nothing to remove either way. Both candidate mechanisms are geometric.
• The fix target differs between them: a tab would need a tab-stop rule, whereas a grid column needs the column width to match what PowerPoint reserves between the bullet glyph and the indent.

What still needs settling before implementing, and I have not done it: confirm which of the two paths this paragraph actually takes (fixed_text_list_hanging_indent_pt(style).is_some() decides), then measure the first text glyph's x-origin in GT against the output with mutool draw -F trace. The report already establishes that continuation lines agree at x = 99.00pt on both sides, so whatever differs is confined to the first line — which is the signature of a first-line-only offset such as a marker cell that is too wide, rather than a wrong indent.

I am leaving this open rather than guessing between the two mechanisms.

[developer0hye]

Fixed in #793.

The reported effect was right; the mechanism was slightly different. Nothing inserts a space between the bullet and the text. fixed_text_list_marker appends a space to the marker ("• "), and the hanging-indent branch then appends the tab that carries the gap to the indent. Together they are two separators.

Measured on page 28, first body glyph of the first bullet, from mutool draw -F trace with the full affine applied:

	first body glyph x
reference	99.01pt
before	101.60pt
after	99.00pt

The bullet stays at 72.00pt throughout.

Why removing a space moves text by more than a space is worth recording: the tab advances to a stop. The space pushed the marker past the intended stop, so the tab went to the next one. Where the marker plus its space still fits before the stop, the fix removes only the invisible space glyph and nothing shifts at all — poi_sample page 1 is exactly that, visible glyph positions byte-identical either way.

Scope: only the unordered hanging-indent branch. The non-hanging path gets no tab and still needs the space; the ordered-list grid path has its own separator by design.

One limit, stated on the PR too: 11 of 73 fixtures change and I measured the indent exactly on this deck only. I attempted to establish direction on the others by matching glyphs to a LibreOffice reference, and the matcher proved too noisy to trust (mean |dx| of 24–45pt, pairing repeated characters across the page). So the breadth is confirmed, the direction elsewhere is not.