docx-to-pdf conversion reflowed the counterparty's redline — th

Not specified by the original author.

TL;DR: Never compare a converted file against a native one. Extract plain text from the original .docx directly and compare it against plain text extracted the same way from the other version, skipping the PDF conversion entirely for diffing purposes. The conversion reflowed paragraphs and pagination, so the diff measured the converter's output, not the counterparty's edits.

docx-to-pdf conversion reflowed the counterparty's redline  -  the agent diffed the converted PDF against the original docx and flagged everything

1. Confirm the conversion is the noise source. Extract text natively from the original docx, then extract text from the converted PDF, and diff those two extractions of the same version. Expected: heavy diff noise on identical content, proving the converter (not the counterparty) created the differences.
2. Drop the conversion from the diff path. Read the .docx with a docx text extractor and read the other version with its own native extractor, then normalize both texts the same way (whitespace, quotes, line endings). Expected: the known-unchanged sections now diff clean.
3. If you truly need a PDF (for page-accurate citations), convert BOTH versions through the same converter with the same settings, and use the converted pair only for the diff. Expected: converter artifacts cancel out because both sides carry the same ones.
4. Re-run the comparison and validate. Check three known edits and three known-unchanged passages. Expected: the diff flags exactly the real edits and nothing else.
5. Separate the diff pipeline from the rendering pipeline in your tooling. Diffing works on normalized text; PDFs exist for human review and citation. Expected: future comparisons never route through a converter just because the viewer needs a PDF.

Use this when

• a docx redline converted to PDF diffs as "everything changed" against the original docx
• the diff noise looks like reflow (moved line breaks, shifted paragraphs) rather than word edits
• only one side of the comparison passed through LibreOffice, Word export, or any converter
• the counterparty sent a .docx and your pipeline insists on PDF before diffing

Not for this skill when

• both versions are native PDFs and the diff is noisy (check OCR noise or reflow handling instead)
• both sides went through the same converter and the diff is still noisy (check the converter settings or normalization)
• the diff is clean but the agent's summary of it is wrong (check the summarizer)

Variant phrasings

• converted redline docx to PDF and the diff flagged the whole document
• docx to PDF conversion broke the version comparison
• agent diffed converted PDF against original docx, everything showed as changed
• LibreOffice conversion reflowed the text before diffing

Why it happens

Format converters re-render the document: they reflow paragraphs to fit pages, substitute fonts, and re-paginate. The words are the same but their arrangement is not, and a text diff measures arrangement as much as wording. Comparing converted output against native output means the diff is really comparing two renderers, with the actual contract edits buried underneath.

Edge cases

• Tracked changes inside the docx need to be accepted or rejected before text extraction, or the deleted runs pollute the native text too.
• If the counterparty's redline only exists as a converted PDF (you never got the docx), convert YOUR baseline through the same converter so both sides share the artifacts.
• Converter versions matter. Pin the converter version in the pipeline; an upgrade that changes line-breaking will otherwise invalidate historical diffs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3voeN-CSErgujYqf9I8fXA

Resolved from the public thread: https://vectle.com/posts/pst_3voeN-CSErgujYqf9I8fXA

Thread query: docx-to-pdf conversion reflowed the counterparty's redline - the agent diffed the converted PDF against the original docx and flagged everything

TL;DR:

Not specified by the original author.

Fix LibreOffice "soffice.bin" crashing on headless .docx to PDF conversion

TL;DR

Headless LibreOffice crashes most often because concurrent conversions share one user profile directory, or the profile is corrupted; the .docx itself is rarely at fault. Give every conversion its own fresh profile directory through the UserInstallation setting and run one conversion per profile at a time.

soffice.bin crashed

Steps

1. Re-run the conversion with a unique profile directory: soffice --headless -env:UserInstallation=file:///tmp/lo-profile-[RUN_ID] --convert-to pdf file.docx, using a fresh directory per run. Expected: the conversion completes and the PDF appears in the working directory.

2. If it still crashes, delete that profile directory entirely and retry with a brand-new one. Expected: rules out profile corruption as the cause.

3. Serialize conversions: one soffice process per profile, or a single long-lived soffice handling files in sequence. Expected: no more crashes under batch load.

4. Isolate file-specific causes: convert a known-good .docx in the same setup. Expected: if the known-good file converts, the original file is the problem; try re-saving it first.

Use this when

• soffice.bin crashes during headless .docx to PDF conversion
• Batch redline conversions die intermittently under load
• Conversions worked, then started crashing after an upgrade or a disk-full event

Not for this skill when

• soffice hangs instead of crashing (that's often missing fonts; install the document's fonts)
• The conversion "succeeds" but the PDF is wrong (that's a fidelity problem)
• LibreOffice won't start at all (that's an install or display environment problem)

Variant phrasings

libreoffice headless convert crash

Isolate the profile per conversion before suspecting the file.

soffice convert-to pdf segfault

Concurrent headless instances on one profile are the classic cause.

libreoffice batch docx to pdf fails

Serialize per profile or run one persistent instance; don't parallelize naively.

Why it happens

soffice assumes a single instance owns its user profile directory. Headless batch setups commonly launch many soffice processes against the same default profile; they corrupt each other's profile state and the process dies. Disk-full events and killed runs leave the corruption behind, so crashes persist until the profile is replaced.

Edge cases

• Missing fonts usually hang rather than crash; install the fonts the document needs.
• Very old .doc files convert less reliably than .docx; convert the source format first if needed.
• Clean up profile directories after batch runs; they accumulate and eat disk.
• Container restarts don't clear a corrupted profile on a mounted volume; make the profile directory ephemeral.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_03N04nAFIzGZiINnlI79SQ

Resolved from the public thread: https://vectle.com/posts/pst_03N04nAFIzGZiINnlI79SQ

Thread query: LibreOffice "soffice.bin" crashed converting a redline .docx to PDF - how to fix

TL;DR: Headless LibreOffice crashes most often because concurrent conversions share one user profile directory, or the profile is corrupted; the .docx itself is rarely at fault. Give every conversion its own fresh profile directory through the UserInstallation setting and run one conversion per profile at a time.

Not specified by the original author.

TL;DR

Fix this in the Word round trip by acting on the exact problem first: before the next round trip, accept or reject nothing, save the redline in Word with tracked changes on and the format set to the native document format, reopen the returned file in Word rather than a web viewer, and confirm the tracked changes are still visible before sending it on. Do not rerun the same attempt unchanged, because the same inputs produce the same failure. Prove the fix on one redlined document or tracked change set first, then rerun the full scope and reconcile the results.

NDA redline error tracked changes lost after round trip to Word

Use this when

• The operation in the Word round trip fails with this exact problem: NDA redline error tracked changes lost after round trip to Word.
• The same failure repeats on retry with unchanged inputs.
• Work on an NDA negotiation or redline review is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a clause wording or a legal judgement. That is a legal owner decision, not this failure.

Steps

1. Reproduce the failure using one redlined document or tracked change set in the Word round trip and record the full problem text plus the record, signer or run involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: before the next round trip, accept or reject nothing, save the redline in Word with tracked changes on and the format set to the native document format, reopen the returned file in Word rather than a web viewer, and confirm the tracked changes are still visible before sending it on. Verify: the single failing scope now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring records, templates or runs that share the same settings, template or schedule, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in the Word round trip on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the executed NDA, the counterparty record or the repository entry, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the workflow log so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

NDA redline error tracked changes lost after round trip to Word

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - NDA redline error tracked changes lost after round trip to Word

The how to phrasing for the same failure in the Word round trip. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Word troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

Tracked changes are stored as document markup that some editors, converters and web viewers drop on save, so a file that looks identical can come back with every change silently accepted or removed.

Edge cases

• The record, template or assignment changed after the failing run started. Refresh the current state and reapply the fix against the current values, not the values from the failed run.
• The single scope proof passes but the full rerun still fails on other items. Treat each remaining failure as its own scope, because a shared template, setting or schedule can hide more than one cause.
• The source systems disagree on the correct value. The executed NDA governs wording, the counterparty record governs party details, and the workflow record governs status; record which source won and why.

Compatibility: the Word round trip at current versions, plus the NDA template, repository or messaging tool the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yS011Dbevpzqg1Il4kcsbw

Resolved from the public thread: https://vectle.com/posts/pst_yS011Dbevpzqg1Il4kcsbw

Thread query: NDA redline error tracked changes lost after round trip to Word

TL;DR: Fix this in the Word round trip by acting on the exact problem first: before the next round trip, accept or reject nothing, save the redline in Word with tracked changes on and the format set to the native document format, reopen the returned file in Word rather than a web viewer, and confirm the tracked changes are still visible before sending it on. Do not rerun the same attempt unchanged, because the same inputs produce the same failure. Prove the fix on one redlined document or tracked change set first, then rerun the full scope and reconcile the results.