Windows: render_docx.py passes invalid file:// URI to LibreOffice UserInstallation
Bug: render_docx.py builds invalid Windows file:// URI for LibreOffice UserInstallation
Component
Codex App / documents skill / render_docx.py
Environment
- OS: Microsoft Windows 10.0.26200, x64
- Codex CLI:
codex-cli 0.142.2 - LibreOffice:
LibreOffice 26.2.2.2 1f77d10d6938fd34972958f64b2bcfa54f8b1ba5 - Shell: PowerShell
Summary
On Windows, render_docx.py passes a Windows path to LibreOffice as:
-env:UserInstallation=file://C:\Users\...\AppData\Local\Temp\soffice_profile_xxx
LibreOffice fails before producing the PDF and prints:
libpng error: Write Error
The same conversion succeeds when UserInstallation is expressed as a valid Windows file URI:
-env:UserInstallation=file:///C:/Users/.../AppData/Local/Temp/soffice_profile_xxx
Reproduction
- On Windows, run the bundled documents renderer against any valid
.docx:
& "<codex-runtime-python>\python.exe" `
"<codex-documents-skill>\render_docx.py" `
"D:\path\sample.docx" `
--output_dir "D:\path\rendered" `
--verbose `
--emit_pdf
- The script constructs a LibreOffice command like:
soffice -env:UserInstallation=file://C:\Users\...\AppData\Local\Temp\soffice_profile_xxx --invisible --headless --norestore --convert-to pdf --outdir C:\Users\...\AppData\Local\Temp\soffice_convert_xxx D:\path\sample.docx
- LibreOffice exits with code 1 and stderr:
libpng error: Write Error
- No PDF is produced, and
render_docx.pyraises:
RuntimeError: Failed to produce PDF for rasterization (direct and ODT fallback).
Expected behavior
render_docx.py should produce a PDF and PNG pages on Windows when LibreOffice is installed and the input DOCX is valid.
Actual behavior
PDF generation fails because LibreOffice receives an invalid UserInstallation file URI.
Evidence
The same input document and LibreOffice installation were tested with two UserInstallation forms:
file://D:\...\lo_profile -> fails with "libpng error: Write Error"
file:///D:/.../lo_profile -> succeeds and generates the PDF
Running LibreOffice without the isolated profile can also generate the PDF, but that is not a good long-term workaround because it uses the default user profile and can be affected by profile locks or user configuration.
Likely cause
render_docx.py currently constructs the argument by string concatenation:
"-env:UserInstallation=file://" + user_profile
On Windows this produces a non-standard file URI with backslashes and no third slash after file:.
Suggested fix
Use platform-aware URI construction, for example:
from pathlib import Path
"-env:UserInstallation=" + Path(user_profile).resolve().as_uri()
This produces file:///C:/... on Windows and valid file URIs on other platforms.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗