Testing Microsoft Publisher Conversion on Linux: What Worked, What Broke, and Why Fidelity Matters

Microsoft Publisher's retirement creates a practical problem for anyone maintaining older publications: what happens when you have .pub files but no longer have access to the application that created them?

Microsoft has recommended converting existing publications into other formats. PDF is an obvious choice when the objective is to preserve a document for viewing or distribution. But converting a file and preserving its original layout are not necessarily the same thing.

I wanted to investigate that distinction while implementing Publisher conversion support for a web-based document utility platform.

Rather than relying on documentation stating that a particular format was supported, I tested actual Publisher documents through several conversion routes.

The investigation included:

• LibreOffice 24.2 and 26.8 on Linux.
• Font compatibility testing.
• Scribus and its scripted import interface.
• Direct libmspub utilities.
• Editable OpenDocument Drawing (ODG) output.
• Direct DOCX export.
• PDF-to-PNG rendering using Poppler.

Some conversions worked. Some failed immediately. Others generated perfectly valid output files that were visually unsuitable for their intended purpose.

Those differences became the most useful part of the investigation.

1. The problem: what does a successful conversion actually mean?

Microsoft Publisher was widely used for brochures, newsletters, flyers, invitations and other page-layout documents.

Those documents can contain more than ordinary paragraphs. A publication may rely on independently positioned text boxes, layered images, unusual fonts, linked text containers and carefully arranged shapes.

Converting that material into another format introduces several different questions.

File conversion: Can the application read the source and generate an output file?

Visual fidelity: Does the converted publication still resemble the original?

Practical editability: Can someone open the result and meaningfully modify its contents?

I decided to evaluate these separately.

A command that exits successfully is evidence that a processing operation completed. It is not, by itself, evidence that the resulting document is visually correct.

Likewise, a publication that looks reasonable as a PDF may not provide a useful way to update its original text, images or design.

2. The testing environment

My initial conversion work was performed on an Ubuntu 24.04 server running LibreOffice 24.2.7.2.

I subsequently built an isolated test environment using Docker Desktop on Windows, with LibreOffice 26.8.2.2 running inside a Linux container.

The relevant software included:

I used separate LibreOffice user profiles for the conversion tests to avoid interfering with an existing application profile.

The test documents were three Publisher fixtures identified during the investigation as Apache POI samples:

These were useful because the files were not equally complex.

The simple publication provided a basic compatibility test. The brochure and newsletter exposed problems with text positioning, overlapping content and page composition.

This was a small exploratory test set, not a comprehensive compatibility benchmark across every Publisher version.

3. Baseline: converting Publisher to PDF

The original Ubuntu installation reported:

/usr/bin/libreoffice --version 

LibreOffice 24.2.7.2 420(Build:2) 

Publisher documents were imported as LibreOffice Draw documents and exported using the draw_pdf_Export filter.

The application-side command construction used Symfony Process, including an isolated user profile:

$process = new Process([ config('services.libreoffice.path', '/usr/bin/libreoffice'), '-env:UserInstallation=file://' . $profileDirectory, '--headless', '--nologo', '--nodefault', '--nofirststartwizard', '--convert-to', 'pdf:draw_pdf_Export', '--outdir', $outputDirectory, $input, ]); 

The results were mixed.

The simple Publisher sample converted with an acceptable appearance.

The brochure also converted, retaining two pages, text, images and much of its overall structure. However, the layout was visibly damaged.

Text wrapped differently inside its containers. Some headings were incorrectly sized or positioned. Images and decorative elements overlapped text in places where the original publication had a more deliberate arrangement.

The newsletter was worse.

Although it produced a four-page PDF, several article sections had overlapping paragraphs. Content from different text regions appeared intermingled, and the intended multi-column layout was no longer reliably readable.

The PDF conversion worked technically, but the complex documents were not preserved faithfully.

This was the first important result.

A valid PDF can still be a poor migration outcome.

[Figure 1: Original Publisher brochure and converted PDF, showing text-box and image positioning differences.]

[Figure 2: Converted newsletter, showing overlapping article content and displaced text.]

4. Could missing fonts explain the layout damage?

Font substitution was one of the first possibilities I investigated.

The original Linux environment did not have several Microsoft fonts installed.

This matters because the dimensions of a text box do not necessarily change when its original font is unavailable. If the replacement font has different character widths, line heights or spacing, the text may wrap differently.

A paragraph that originally fitted inside a fixed container may need an additional line after substitution.

I installed the Microsoft core fonts using the Ubuntu ttf-mscorefonts-installer package and verified font matching for fonts including Arial, Times New Roman, Trebuchet MS and Comic Sans MS.

I then repeated the brochure conversion.

There was a slight improvement, but the main layout defects remained.

The text-box positioning and more substantial content overlaps were not resolved.

This did not establish that fonts were irrelevant. They clearly affect document layout.

It established something narrower: missing fonts were not sufficient to explain the conversion problems observed in this brochure.

The investigation therefore needed to move beyond font substitution.

5. Would a newer LibreOffice version improve the result?

The next experiment was to test LibreOffice 26.8.2.2 independently of the production installation.

I downloaded the official Linux Debian archive and built a Docker image containing the newer version.

The container reported:

docker run --rm swiftvecto-pub-lo268 --version 

LibreOffice 26.8.2.2 9dea406ab7695df6325b11b0e19fdca8db4b7276 

I then converted the brochure and newsletter:

docker run --rm `  --mount "type=bind,source=$((Get-Location).Path),target=/work" `  swiftvecto-pub-lo268 `  -env:UserInstallation=file:///tmp/lo-pub-profile `  --headless `  --convert-to pdf:draw_pdf_Export `  --outdir /work/output `  /work/SampleBrochure.pub `  /work/SampleNewsletter.pub 

The command output showed two successful exports:

convert /work/SampleBrochure.pub as a Draw document -> /work/output/SampleBrochure.pdf using filter : draw_pdf_Export convert /work/SampleNewsletter.pub as a Draw document -> /work/output/SampleNewsletter.pdf using filter : draw_pdf_Export 

I verified the generated files:

Get-ChildItem .\output\*.pdf | Select-Object Name, Length 

Name Length ---- ------ SampleBrochure.pdf 226390 SampleNewsletter.pdf 367071 

The files existed, contained multiple pages and were not empty.

However, visual inspection was disappointing.

The brochure still contained incorrect text wrapping, displaced headings and overlapping objects. The newsletter continued to show serious paragraph collisions and unreadable areas.

I could not identify a meaningful visual improvement for these documents.

There is an important qualification here: the Docker environment and original production environment did not initially have exactly the same font installations.

This was therefore not a perfectly controlled renderer benchmark.

It was sufficient, however, to establish that moving to LibreOffice 26.8 did not resolve the most significant visual defects in the documents I tested.

A newer application version did not automatically mean a better conversion.

6. Testing another importer: Scribus

I also investigated Scribus 1.6.1.

Because this was a Linux server without a normal graphical desktop session, I used Xvfb to provide a virtual display for scripted processing.

The conversion attempt used Scribus's Python interface to open a Publisher document and export a PDF.

It did not work as expected.

The importer reported:

ERROR: Parsing failed! 

The workflow subsequently produced a PDF of approximately 1,244 bytes.

On inspection, that file contained one essentially empty page rather than the expected two-page brochure.

This was an important failed test.

A generated PDF is not necessarily proof that a source document was successfully imported. Some workflows can reach an export stage even though the earlier import operation did not produce useful content.

I treated the Scribus result as a failure rather than a successful conversion.

It also highlighted why automated document-processing systems should validate more than process exit codes and output filenames.

7. Testing libmspub directly

LibreOffice's Publisher import capability uses the open-source libmspub library, so I wanted to see whether accessing the library's utilities directly could provide a useful alternative output.

I launched a temporary Ubuntu 24.04 container and installed the available tools:

apt-get update apt-get install -y libmspub-tools 

The installed version was 0.1.4.

Attempt 1: PUB to SVG

The pub2xhtml utility describes itself as a Publisher-to-SVG converter.

I tested the brochure:

pub2xhtml \ /work/SampleBrochure.pub \ /work/libmspub-output/SampleBrochure.svg 

The result was:

ERROR: SVG Generation failed! 

I then attempted the simple sample:

pub2xhtml \ /work/Sample.pub \ /work/libmspub-output/Sample.svg 

That returned a different error:

ERROR: Unsupported file format! 

Neither test produced a usable SVG document. The generated files were empty.

These errors should not be conflated. The utility reported an unsupported format for one input and an SVG-generation failure for the other.

I did not establish the precise internal cause of either failure.

Attempt 2: raw diagnostic output

The package also provided pub2raw, a utility intended for testing libmspub.

After checking its argument syntax, I ran:

pub2raw /work/SampleBrochure.pub > /work/libmspub-output/SampleBrochure.raw 2> /work/libmspub-output/pub2raw-error.log 

Both generated files were zero bytes.

There was no useful diagnostic content and no error text.

I had not captured the utility's exit code, so I could not determine from this evidence whether parsing had completed successfully but produced no output, or failed silently.

The direct library experiments did not provide a viable alternative conversion route.

That was useful information, but not a reason to conclude that the library could never be improved or that its behaviour was identical for every Publisher file.

8. A different outcome: converting Publisher to editable ODG

At this point, I changed the question.

Instead of asking only whether a Publisher document could be reproduced faithfully as a PDF, I wanted to know whether its underlying content could be recovered in a form that remained editable.

I tested conversion to OpenDocument Drawing (.odg).

Using the LibreOffice 26.8 Docker environment:

docker run --rm `  --mount "type=bind,source=$((Get-Location).Path),target=/work" `  swiftvecto-pub-lo268 `  -env:UserInstallation=file:///tmp/lo-pub-odg-profile `  --headless `  --convert-to odg:draw8 `  --outdir /work/odg-output `  /work/SampleBrochure.pub `  /work/SampleNewsletter.pub 

The results were promising:

convert /work/SampleBrochure.pub as a Draw document -> /work/odg-output/SampleBrochure.odg using filter : draw8 convert /work/SampleNewsletter.pub as a Draw document -> /work/odg-output/SampleNewsletter.odg using filter : draw8 

The generated files were:

Name Length ---- ------ SampleBrochure.odg 102569 SampleNewsletter.odg 190794 

I opened the ODG documents in LibreOffice Draw to test whether they contained meaningful editable content.

The important result was that individual text fields and objects in the brochure remained editable. They were not simply flattened into a single image of each page.

Text could be changed within the converted document, and recovered page elements could be worked with independently.

I also observed no noticeable difference in practical ODG editability between the LibreOffice 24.2 and 26.8 versions tested.

That observation does not establish that their internal output structures were identical. It means I found no meaningful editability improvement attributable to the newer version.

The overall result was still significant.

Although the original layout could require correction, ODG offered a practical way to recover and continue editing the publication's contents.

For certain migration scenarios, that may be more valuable than a PDF that merely looks similar to the original.

[Figure 3: Converted brochure opened in LibreOffice Draw, with an individual text object selected for editing.]

9. What about converting directly to DOCX?

The next question was whether the Publisher documents could be converted into Microsoft Word's DOCX format.

I attempted a direct export using the Office Open XML Text filter:

docker run --rm `  --mount "type=bind,source=$((Get-Location).Path),target=/work" `  swiftvecto-pub-lo268 `  -env:UserInstallation=file:///tmp/lo-pub-docx-profile `  --headless `  --convert-to docx:"Office Open XML Text" `  --outdir /work/docx-output `  /work/SampleBrochure.pub `  /work/SampleNewsletter.pub 

LibreOffice recognised each input as a Draw document, but the export failed.

The brochure produced:

convert /work/SampleBrochure.pub as a Draw document -> /work/docx-output/SampleBrochure.docx using filter : Office Open XML Text Error: Please verify input parameters... (SfxBaseModel::impl_store <file:///work/docx-output/SampleBrochure.docx> failed: 0xc10(Error Area:Io Class:Write Code:16)) 

The newsletter produced the same class of error.

This was not evidence that DOCX was an impossible destination under all circumstances.

It showed that the direct Draw-to-DOCX export route I attempted was not supported successfully by that workflow.

Publisher and Word also organise document content differently. Publisher's positioned page-layout objects do not necessarily map cleanly to a Word document's structure.

A different approach might involve extracting text and images, reconstructing a DOCX document and accepting that some layout information would be lost.

I did not implement that approach during this investigation.

Rather than claim a working converter from a failed export, I left DOCX conversion for separate research.

10. Converting the resulting PDF into images

One of the more straightforward experiments involved rendering converted Publisher pages as PNG images.

The aim was not to improve layout fidelity. It was to determine whether a successfully generated PDF could be used as an intermediate format for producing individual page images.

I used Poppler's pdftoppm utility inside the test container:

docker run --rm `  --entrypoint /bin/bash `  --mount "type=bind,source=$((Get-Location).Path),target=/work" `  swiftvecto-pub-lo268 `  -c 'pdftoppm -f 1 -l 2 -r 150 -png /work/output/SampleBrochure.pdf /work/image-output/brochure' 

The command completed without reporting an error.

The resulting files were:

brochure-1.png 262755 bytes brochure-2.png 706529 bytes 

Both pages of the brochure had been rendered at 150 DPI.

This established a useful two-stage pipeline:

Publisher (.pub) | v Converted PDF | v Poppler renderer | v Individual PNG page images 

The same concept was subsequently used in a web-based PUB-to-Images utility.

However, it is important to understand what this pipeline does not achieve.

If the intermediate PDF already contains overlapping paragraphs or incorrectly positioned images, the PNG output will reproduce those errors.

Rasterisation preserves the appearance of the intermediate representation. It cannot reconstruct the layout of the original Publisher document.

11. Results across the conversion routes

The following table summarises the tests rather than claiming general compatibility for every Publisher document.

The most important distinction was not simply successful versus failed conversion.

It was whether the output met the intended requirement.

For viewing, I needed readable pages with acceptable layout preservation.

For editing, I needed independently accessible text, images and other document elements.

For archiving, I needed confidence that important content had not been lost or displaced.

The same output format did not satisfy every requirement.

12. What I would recommend for legacy Publisher documents

Microsoft's official retirement guidance recommends preserving existing Publisher documents by converting them into other formats, including PDF. It also identifies Word and PowerPoint as alternatives for several common Publisher use cases.

That is Microsoft's documented guidance.

My testing addresses a narrower question: what can happen when alternative Linux-based tools are used to import existing PUB files?

Based on these results, I would approach a Publisher migration according to the actual requirement.

If Microsoft Publisher is still available through a functioning perpetual installation, exporting directly from the original application is a sensible option to evaluate first, particularly when visual fidelity matters. I did not benchmark direct Publisher exports in this investigation.

For organisations working without Publisher, alternative conversion tools can provide access to the contents, but the output should be reviewed, especially for newsletters, brochures and other complex publications.

If the objective is continued editing rather than static distribution, an editable drawing format such as ODG may be useful. The recovered content can still require layout adjustments, but at least the publication can remain workable.

For image output, rendering an intermediate PDF is technically straightforward, provided the PDF is already acceptable.

For DOCX, I would not promise reliable conversion on the basis of a supported filename or export filter alone. The actual document structure and selected conversion path matter.

For large archives, I would also recommend retaining the original PUB files alongside any converted outputs.

Conversion should not be treated as a reason to discard the only existing source document.

13. Limitations of this investigation

The testing was deliberately practical rather than exhaustive.

It used three named Publisher fixtures, not a representative sample of all Publisher versions or real-world publication designs.

The LibreOffice comparison was not initially performed under identical font environments.

I did not perform automated pixel-difference analysis or assign numerical fidelity scores.

I also did not inspect the internal source code of libmspub deeply enough to identify a specific parsing defect.

The ODG editability assessment was based on opening and interacting with the converted documents, rather than a complete automated audit of every object.

These limitations matter because they define what the results can and cannot establish.

I can say that the tested complex Publisher files converted poorly to PDF under the tested LibreOffice versions.

I cannot say that every Publisher document will convert poorly, or that no other conversion tool could produce a better result.

I can say that the ODG files retained meaningful editability in my tests.

I cannot say that ODG is a perfect replacement for Microsoft Publisher or that every publication feature survives intact.

Conclusion

The investigation changed how I think about legacy document conversion.

Initially, the question seemed straightforward: could I open a Publisher file on Linux and generate another format?

The answer was often yes.

But a successful export did not necessarily produce a document that was suitable for printing, sharing or further editing.

The simple Publisher sample converted acceptably. The more complex brochure and newsletter exposed serious layout-fidelity problems that were not resolved simply by installing additional fonts or switching from LibreOffice 24.2 to 26.8.

Scribus and direct libmspub utilities did not produce a useful alternative through the approaches tested.

Direct DOCX export failed.

ODG, however, demonstrated that recovering editable content could still be worthwhile, even when the original appearance was not preserved perfectly.

And PDF-to-PNG rendering showed how a successful intermediate conversion could support additional output formats, while also carrying forward any existing defects.

For a legacy document migration, generating an output file is only the beginning of validation. The useful question is whether that output preserves what the organisation actually needs: appearance, information, editability, or some combination of the three.

That distinction matters more than whether a converter reports success.

References

• Microsoft: Microsoft Publisher will no longer be supported after October 2026
• Microsoft: End of support for Office 2021
• LibreOffice
• The Document Foundation: libmspub
• Poppler PDF rendering tools

The conversion commands and results documented above come from the practical tests performed during this investigation. Microsoft retirement information is based on Microsoft's published support documentation.