Problem
Sources/OOXMLSwift/IO/Phase7OMathSplicer.swift (or wherever inline OMath splicing happens — surfaced via thesis rescue v0.27.0 output) emits <w:rFonts> inside math elements as non-self-closing:
<w:rPr><w:rFonts w:ascii="Cambria Math" w:eastAsia="DFKai-SB" w:hAnsi="Cambria Math"></w:rFonts><w:i></w:i><w:iCs></w:iCs>...</w:rPr>
instead of the standard self-closing form:
<w:rPr><w:rFonts w:ascii="Cambria Math" w:eastAsia="DFKai-SB" w:hAnsi="Cambria Math"/><w:i/><w:iCs/>...</w:rPr>
Confirmed in kiki830621/collaboration_guo_analysis#20 thesis output:
- Body text rFonts: 91 elements, 100% self-closing (✓ matches target)
- Phase 7 OMath splice rFonts (inside
<m:ctrlPr> / <m:rPr>): 344 elements, 0% self-closing
Type
bug
Impact
- Technically valid XML — balanced open/close tags, parses fine via xmllint, python-docx, lxml.
- Practically: Office on Mac renders OK in current testing, but:
- Larger byte size for no reason (~30 bytes per occurrence × 344 = ~10KB bloat in thesis docx).
- Diverges from canonical Word-emitted XML pattern → some legacy Office variants (especially Office 2010 / 2013 LTSC) and stricter sanitizers/validators may reject or flag.
- Forensic / diff tooling treats
<w:rFonts ...></w:rFonts> and <w:rFonts .../> as different bytes — round-trip byte-equality tests fail unnecessarily.
Reproduction
cd /path/to/thesis-rescue-output
unzip -p docs/...rescue-swift-v0.27.0.docx word/document.xml | \
grep -oE '<w:rFonts\b[^>]*[^/]>' | wc -l
# Expected: 0
# Actual: 344 (all inside <m:ctrlPr> / <m:rPr> blocks from Phase 7 OMath splice)
Direct cause: ooxml-swift's OMath element serializer (likely in Sources/OOXMLSwift/Models/MathComponent.swift or MathRunPropertiesSerializer) emits empty elements as <tag attrs></tag> instead of <tag attrs/>. Body-level run serializer (Run.toXML) correctly uses self-closing form.
Expected
All <w:rFonts> elements (and other empty math sub-elements like <w:i>, <w:iCs>, <w:kern>, <w:sz>, <w:szCs> inside math <w:rPr>) emitted as self-closing.
Surface
Surfaced during /idd-plan #67 tangential sweep. Distinct concern from #67 (which is reader-side body sectPr loss) — this is writer-side math emission style mismatch.
Source
kiki830621/collaboration_guo_analysis#20 — NTPU thesis rescue, observed in v0.27.0 output during tangential investigation while diagnosing thesis font-rendering issue.
Problem
Sources/OOXMLSwift/IO/Phase7OMathSplicer.swift(or wherever inline OMath splicing happens — surfaced via thesis rescue v0.27.0 output) emits<w:rFonts>inside math elements as non-self-closing:instead of the standard self-closing form:
Confirmed in kiki830621/collaboration_guo_analysis#20 thesis output:
<m:ctrlPr>/<m:rPr>): 344 elements, 0% self-closingType
bug
Impact
<w:rFonts ...></w:rFonts>and<w:rFonts .../>as different bytes — round-trip byte-equality tests fail unnecessarily.Reproduction
Direct cause: ooxml-swift's OMath element serializer (likely in
Sources/OOXMLSwift/Models/MathComponent.swiftorMathRunPropertiesSerializer) emits empty elements as<tag attrs></tag>instead of<tag attrs/>. Body-level run serializer (Run.toXML) correctly uses self-closing form.Expected
All
<w:rFonts>elements (and other empty math sub-elements like<w:i>,<w:iCs>,<w:kern>,<w:sz>,<w:szCs>inside math<w:rPr>) emitted as self-closing.Surface
Surfaced during /idd-plan #67 tangential sweep. Distinct concern from #67 (which is reader-side body sectPr loss) — this is writer-side math emission style mismatch.
Source
kiki830621/collaboration_guo_analysis#20 — NTPU thesis rescue, observed in v0.27.0 output during tangential investigation while diagnosing thesis font-rendering issue.