Repository navigation
Word to PDF through LibreOffice: keep a footnote's number inside its brackets - #1130
Open
KnifeLemon wants to merge 1 commit into
Open
KnifeLemon wants to merge 1 commit into
KnifeLemon wants to merge 1 commit into
Conversation
…brackets
Word lets a footnote's number sit anywhere in the note's text, and Arabic papers
commonly put it in brackets: "(" ref ")". LibreOffice's DOCX import drops the
number from that place and draws its own label at the start of the note, so the
note comes out as "1()", which reads "()1" in a right-to-left paragraph.
For such documents LibreOffice now gets a copy in which every reference has an
invisible custom mark followed by its number as text, and every note has its
number as text where Word has it. Documents whose numbers depend on the pages or
use another number format stay as they were; endnotes stay LibreOffice's.
Refs #620
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #620
Cause
Word lets a footnote's number sit anywhere in the note's text, and Arabic papers commonly put it in brackets:
(+w:footnoteRef+). LibreOffice's DOCX import drops the number from that place and draws its own label at the start of the note. The brackets stay behind, so the note comes out as1(), which on the page reads()1in a right-to-left paragraph. That is the report's symptom. References in the body text were fine, whichever way their brackets were typed.So this isn't a bidi problem, and it also affects left-to-right documents.
Fix
DocxNoteMarksruns before LibreOffice renders a Word document (PDF, PNG, SVG, EMF, WMF). For a document with text before a note's number, LibreOffice gets a copy where:customMarkFollowswith U+200B), which replaces LibreOffice's label, followed by its number as text in the reference's formatting;A custom mark doesn't count in the numbering, so all footnotes change together and the numbers are worked out here. A document stays as it was if its numbers restart per page or section, or use a format other than decimal or Hindi digits. Endnotes stay LibreOffice's, because I couldn't verify them.
How this was checked
build/fetch-engines.ps1(pinned, SHA-256 checked), all ofDocxNoteMarksTestspasses, includingThe_number_stays_inside_its_brackets_in_the_pdf, which runs the whole route through the job queue.(1)and(2), and the body marks keep their own look. The same document given to the same LibreOffice without this change has the number outside its brackets. There is no U+200B in the PDF's extracted text.DocxNoteMarksTestsalso checks the XML thatPreparewrites.CI has no LibreOffice, so the route test skips there. The reporter's own file isn't attached: this fixes the reported symptom in a document built to the layout that causes it.
🤖 Generated with Claude Code