NullPointerException with Aptos Font and wp14:anchorId

Summary

Aspose.Words throws a NullPointerException during Document.save() or Document.updatePageLayout() when ALL of the following conditions are met:

  1. Document contains wp14:anchorId attributes (Word 2010+ drawing anchors) in header/footer images
  2. Document uses Aptos Display font (defined in fontTable.xml and/or theme.xml)
  3. Aptos fonts are installed on the system where Aspose.Words is running

The NPE occurs in internal Aspose.Words code during VML shape rendering/layout calculation.

Environment

  • Aspose.Words Version: 26.2 (Java)
  • Java Version: 17+
  • Operating System: Linux (Amazon Linux 2023, containerized)
  • Font Configuration: Aptos font family installed via fontconfig
  • License: Aspose.Total for Java (licensed, not trial)

Steps to Reproduce

Minimal Reproduction Case

  1. Install Aptos fonts on your Linux system (Aptos-Regular.ttf, Aptos-Bold.ttf, etc.)

    • Aptos is Microsoft’s new default font family (released 2024)
    • Available from Microsoft or font repositories
  2. Load the attached test document (aspose-npe-test.docx)

    • Document has a header with image inside a table cell containing wp14:anchorId="0F61020F"
    • Document uses Aptos Display font in theme.xml and fontTable.xml
    • Document has custom property ClassificationContentMarkingFooterFontProps with value #000000,9,Aptos
    • Important: All elements are required - anchorId attributes, Aptos fonts, table structure, AND custom property referencing Aptos
  3. Convert to PDF using Aspose.Words:

import com.aspose.words.Document;
import com.aspose.words.SaveFormat;

public class AptosNpeTest {
    public static void main(String[] args) throws Exception {
        Document doc = new Document("aspose-npe-test.docx");

        // NPE occurs here when Aptos fonts are installed
        doc.save("output.pdf", SaveFormat.PDF);
    }
}

Expected Behavior

  • Document converts to PDF successfully
  • Aptos Display font is either used (if available) or substituted automatically

Actual Behavior

  • NullPointerException is thrown during Document.save() or Document.updatePageLayout()
  • Stack trace points to internal VML shape rendering code
  • Error: Cannot invoke "com.aspose.words.zzfk.zzWt6()" because "<local4>" is null

Full Stack Trace

java.lang.NullPointerException: Cannot invoke "com.aspose.words.zzfk.zzWt6()" because "<local4>" is null
    at com.aspose.words.zzXIy.zzX1x(Unknown Source)
    at com.aspose.words.zzXIy.zzyf(Unknown Source)
    at com.aspose.words.zzXIy.zzyf(Unknown Source)
    at com.aspose.words.zzXIy.zzWva(Unknown Source)
    at com.aspose.words.zzXBs.zzXvW(Unknown Source)
    at com.aspose.words.zzXBs.zzWDE(Unknown Source)
    at com.aspose.words.zzYmB.zzyf(Unknown Source)
    at com.aspose.words.zzYmB.zzZvX(Unknown Source)
    at com.aspose.words.zzYmB.zzX1x(Unknown Source)
    at com.aspose.words.zzXfh.zz1k(Unknown Source)
    at com.aspose.words.zzXfh.zzX1x(Unknown Source)
    at com.aspose.words.zzZKh.zzk(Unknown Source)
    at com.aspose.words.zzZKh.zzZvX(Unknown Source)
    at com.aspose.words.zzZKh.zzyf(Unknown Source)
    at com.aspose.words.zzXPr.zzWEu(Unknown Source)
    at com.aspose.words.zzXPr.zzX1x(Unknown Source)
    at com.aspose.words.zzXPr.zzyf(Unknown Source)
    at com.aspose.words.zzX82.zzXvW(Unknown Source)
    at com.aspose.words.zzX82.zzWDE(Unknown Source)
    at com.aspose.words.zzX82.zzWsx(Unknown Source)
    at com.aspose.words.zzX82.zzlG(Unknown Source)
    at com.aspose.words.zzW0p.zzlG(Unknown Source)
    at com.aspose.words.zzY5w.zzX1x(Unknown Source)
    at com.aspose.words.zzYch.zzWff(Unknown Source)
    at com.aspose.words.zzWpN.zzYwe(Unknown Source)
    at com.aspose.words.Document.updatePageLayout(Unknown Source)
    at com.aspose.words.zzVSi.zzI6(Unknown Source)
    at com.aspose.words.zzWbd.zzgs(Unknown Source)
    at com.aspose.words.zzZCU.zzZ3t(Unknown Source)
    at com.aspose.words.zzZCU.zzX1x(Unknown Source)
    at com.aspose.words.zzZCU.zzyf(Unknown Source)
    at com.aspose.words.zzZCU.zzFF(Unknown Source)
    at com.aspose.words.Document.zzVVX(Unknown Source)
    at com.aspose.words.Document.zzX1x(Unknown Source)
    at com.aspose.words.Document.zzyf(Unknown Source)
    at com.aspose.words.Document.save(Unknown Source)

Aspose.Words Warnings Before NPE

The following warnings appear before the NPE occurs:

Warning #1: Type=16777216, Description=1721
Warning #2: Type=65536, Description=Import of element 'shapedefaults' is not supported in Docx format by Aspose.Words.
Warning #3: Type=65536, Description=Import of element 'ligatures' is not supported in Docx format by Aspose.Words.
Warning #4: Type=65536, Description=Import of element 'extraClrSchemeLst' is not supported in Docx format by Aspose.Words.
Warning #5: Type=65536, Description=Import of element 'anchorId' is not supported upon VML import by Aspose.Words.
Warning #6: Type=65536, Description=Import of element 'anchorId' is not supported upon VML import by Aspose.Words.
Warning #7: Type=65536, Description=Import of element 'anchorId' is not supported upon VML import by Aspose.Words.

Key Warning: “Import of element ‘anchorId’ is not supported upon VML import by Aspose.Words.”

This suggests Aspose.Words encounters issues importing the wp14:anchorId attribute during VML processing, and the combination with Aptos fonts triggers a null pointer dereference.

Analysis

What is wp14:anchorId?

  • wp14:anchorId is a Word 2010+ Drawing ML attribute
  • Used for uniquely identifying drawing anchors in Word documents
  • Format: <wp:inline wp14:anchorId="12345678">
  • Found in document.xml, header.xml, and footer.xml when images are inserted

Why Does Aptos Font Trigger This?

The NPE only occurs when:

  1. :white_check_mark: Document has wp14:anchorId attributes
  2. :white_check_mark: Aptos fonts are accessible to Aspose.Words (installed on system)

When Aptos fonts are NOT installed, the same document converts successfully because:

  • Aspose.Words uses font substitution (e.g., Liberation Sans)
  • The VML shape rendering path doesn’t encounter the null pointer

This suggests:

  • Aspose.Words has a null pointer bug in VML/anchorId handling code
  • The bug is only triggered when specific fonts (Aptos family) are used
  • Font-specific rendering code path is different and exposes the bug

Documents Without anchorId Work Fine

Documents that use Aptos fonts but don’t have anchorId attributes convert successfully. This confirms the bug requires BOTH:

  • Aptos fonts present
  • anchorId attributes in drawings

Workarounds We Tested

Workaround 1: Remove Aptos fonts from system :white_check_mark: WORKS

  • Uninstall or hide Aptos fonts from system
  • Forces Aspose.Words to use font substitution
  • Document converts successfully

Workaround 2: Remove Aptos Display from fontTable.xml :white_check_mark: WORKS

  • Programmatically remove <w:font w:name="Aptos Display"> from word/fontTable.xml
  • Replace Aptos fonts in theme.xml with Liberation Sans
  • Forces font substitution even when Aptos is installed
  • Document converts successfully

Workaround 3: Exclude Aptos fonts from FontSettings :white_check_mark: WORKS

  • Configure FontSettings to exclude SystemFontSource
  • Only use curated font directories without Aptos
  • Document converts successfully

All workarounds confirm: The NPE is triggered by the combination of anchorId + Aptos font availability.

Important Discovery: Three Elements Required

Initial testing with sanitized documents revealed the exact conditions needed to reproduce the NPE:

  1. :white_check_mark: Image with wp14:anchorId attribute
  2. :white_check_mark: Aptos fonts installed on system
  3. :white_check_mark: Image embedded inside a table structure (triggers VML rendering)
  4. :white_check_mark: Custom document property referencing Aptos font (docProps/custom.xml)

The critical custom property is:

<op:property name="ClassificationContentMarkingFooterFontProps">
  <vt:lpwstr>#000000,9,Aptos</vt:lpwstr>
</op:property>

This property tells Aspose.Words to use Aptos font for footer content marking. When combined with anchorId in a table and Aptos fonts being available, it triggers the VML rendering bug. This explains why not all documents with anchorId + Aptos trigger the issue - the custom property must also be present.

Root Cause Hypothesis

Based on the stack trace and behavior:

  1. Aspose.Words imports the document and encounters wp14:anchorId attributes
  2. Warning shows “anchorId is not supported upon VML import”
  3. During layout calculation (updatePageLayout()), Aspose.Words processes VML shapes
  4. When Aptos fonts are available, a specific rendering code path is taken
  5. This code path has a null pointer bug where it expects an object (<local4>) to be non-null
  6. The object is null because wp14:anchorId handling left it uninitialized
  7. NPE occurs in zzfk.zzWt6() method during VML shape rendering

Request for Fix

Please investigate and fix the null pointer dereference in VML shape rendering when:

  • wp14:anchorId attributes are present
  • Aptos Display font (or Aptos font family) is available

Suggested areas to investigate:

  • VML import code handling wp14:anchorId attributes
  • Font-specific rendering code paths for Aptos fonts
  • Null safety checks in layout calculation for drawing anchors

Test Documents Provided

  1. aspose-npe-test.docx - Sanitized document that reproduces the NPE

    • Contains header with image inside table cell having wp14:anchorId="0F61020F"
    • Complex table structure with multiple cells and formatting
    • Uses Aptos Display in fontTable.xml and theme.xml
    • CRITICAL: Includes custom document property ClassificationContentMarkingFooterFontProps with value #000000,9,Aptos
    • Includes VML namespace declarations that trigger VML rendering
    • Preserves all structural elements (numbering.xml, styles.xml, customXml/, etc.)
    • Sanitized text content (no sensitive customer data)

    ROOT CAUSE COMBINATION:

    1. Image with anchorId in table structure (triggers VML rendering)
    2. Aptos fonts installed on system
    3. Custom document property referencing Aptos font

    All three elements must be present to trigger the NPE.

Impact

This bug affects production document conversion when:

  • Processing Word documents created with Microsoft Word 2024+ (uses Aptos as default font)
  • Running on systems with Aptos fonts installed
  • Documents contain images in headers/footers (commonly used for logos, watermarks)

The bug is a blocker for production use as it causes conversion failures for modern Word documents.

Contact Information

Priority: High (production blocker)
Reproducibility: 100% when all conditions met
Aspose.Words Version: 26.2
License Type: Aspose.Total for Java (licensed)

Please let us know if you need:

  • Additional test documents
  • More detailed diagnostics
  • Specific Aspose.Words API usage examples
  • Stack traces with debug symbols

Thank you for investigating this issue!
aspose-npe-test.docx (43.0 KB)

@pblad
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): WORDSJAVA-3305

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

The issues you have found earlier (filed as WORDSJAVA-3305) have been fixed in this Aspose.Words for Java 26.3 update.