NPE on Linux on missing font

[jaroslav.pubal]

# Bug report — Spire.Doc for Java 14.8.4

## NullPointerException in DrFont when loading RTF with embedded WMF on Linux

**Product:** Spire.Doc for Java 14.8.4 (from BOM `e-iceblue:spire.office:11.8.0`)
**Severity:** conversion fails completely; no fallback, no recoverable error
**Platform:** reproducible on Linux, **not** reproducible on Windows with the same
JAR, same licence and the same input file.

### Environment

| | Linux (fails) | Windows (works) |
|---|---|---|
| OS | Ubuntu on WSL2, kernel 6.18.33-microsoft-standard-WSL2 | Windows 11 Pro 26200 |
| glibc | 2.43 | — |
| JDK | Eclipse Adoptium 17.0.20.1+1 | Microsoft OpenJDK 17.0.18+8 |
| headless | `-Djava.awt.headless=true` | default |
| Spire.Doc | 14.8.4 | 14.8.4 |
| licence | Developer OEM (temporary), applied OK | same |

### Steps to reproduce

```java
Document doc = new Document();
doc.loadFromFile("os_donucovak.rtf"); // <-- throws here
doc.saveToFile("out.pdf", FileFormat.PDF);
```

The input is an RTF containing an embedded **WMF (Windows Metafile)** image.
Two different RTF files with such an image fail identically. The *same document*
saved as `.doc` and `.docx` loads and converts without any problem, on both
platforms — so the trigger is the WMF inside RTF, not the document content.

### Stack trace

```
Exception in thread "main" java.lang.NullPointerException: trueTypeFont
at com.spire.doc.packages.sprsdr.<init>(DrFont.java:58)
at com.spire.doc.packages.sprsdr.<init>(DrFont.java:82)
at com.spire.doc.packages.sproyo.spr???(MfLogFont.java:117)
at com.spire.doc.packages.sprqpo.spr???(MfGdiDC.java:409)
at com.spire.doc.packages.sprgro.spr???(MfSizeScanner.java:219)
at com.spire.doc.packages.sprgro.spr???(MfSizeScanner.java:40)
at com.spire.doc.packages.spraro.spr???(MfPlayerWmf.java:426)
at com.spire.doc.packages.spraro.spr???(MfPlayerWmf.java:467)
at com.spire.doc.packages.spraro.spr???(MfPlayerWmf.java:192)
at com.spire.doc.packages.spraro.spr???(MfPlayerWmf.java:89)
at com.spire.doc.packages.spraro.spr???(MfPlayerWmf.java:43)
at com.spire.doc.packages.spruso.spr???(MfMetafileInfo.java:103)
at com.spire.doc.packages.spruso.spr???(MfMetafileInfo.java:70)
at com.spire.doc.packages.spruso.<init>(MfMetafileInfo.java:43)
at com.spire.doc.packages.spruso.<init>(MfMetafileInfo.java:28)
at com.spire.doc.packages.spruso.<init>(MfMetafileInfo.java:23)
at com.spire.doc.packages.sprgeea.spr???(Unknown Source)
at com.spire.doc.packages.sprgeea.spr???(Unknown Source)
at com.spire.doc.packages.sprifea.spr???(Unknown Source)
at com.spire.doc.packages.sprifea.spr???(Unknown Source)
at com.spire.doc.Document.spr???(Unknown Source)
at com.spire.doc.Document.spr???(Unknown Source)
at com.spire.doc.Document.spr???(Unknown Source)
at com.spire.doc.Document.spr???(Unknown Source)
at com.spire.doc.Document.spr???(Unknown Source)
at com.spire.doc.Document.loadFromFile(Unknown Source)
```

### Analysis

`MfPlayerWmf` replays the metafile, hits a `CreateFontIndirect`-style record,
`MfLogFont` tries to map the LOGFONT to a concrete typeface, and `DrFont`'s
constructor dereferences a `trueTypeFont` that is `null` because the font named
in the metafile is not present on the system. On Windows that font is installed,
so the path never triggers.

**The problem is not that the font is missing — it is that the missing font is
not handled.** A metafile can legitimately reference any font; the expected
behaviour is a substitution (Spire already has `setDefaultSubstitutionFontName`)
or at worst a checked exception, not an NPE from a constructor.

### Workaround (confirmed working)

Register the fonts **statically, before `loadFromFile`**:

```java
Document.setGlobalCustomFontsFolders("/usr/share/fonts/truetype/mswin");
Document doc = new Document();
doc.loadFromFile("os_donucovak.rtf"); // now OK
doc.saveToFile("out.pdf", FileFormat.PDF);
```

The instance method `doc.setCustomFontsFolders(...)` **does not help**, because it
can only be called on an already-constructed `Document`, i.e. after `loadFromFile`
has already thrown. This is worth documenting on your side — the instance and the
static variant are not interchangeable for documents containing metafiles.

With the workaround applied, all 11 test documents convert on Linux and the output
is **pixel-identical** to the Windows output (compared at 120 DPI, difference
0,000 % on every page).

### Request

1. Handle an unresolvable font in `MfLogFont`/`DrFont` by substitution instead of NPE.
2. Document that font folders affecting metafile parsing must be registered via
`setGlobalCustomFontsFolders` before the document is loaded.

[talia.liu]

Hello,

Thank you for reaching out.
Allow me to briefly explain how Spire products handle Word document conversions. Our products rely on reading the corresponding fonts from the local environment. If a font used in the document is not installed, our system will prioritize finding an alternative font that supports the same glyphs (this font fallback mechanism is built into our product by default). However, if no suitable alternative is found, it may result in garbled text (such as squares) or throw an error.
Regarding the issue where loading your file directly causes an error, but loading the fonts first prevents it, our preliminary investigation suggests that this might be caused by other factors. I have logged this issue into our tracking system with the ticket number SPIREDOC-12084. Our development team will conduct a further investigation to address it.
We will notify you immediately once there are any updates.