PdfSaveOptions.DefaultFont has no effect

Aspose.Diagram App Product Family
1

Summary
Converting a .vsdx to PDF via Aspose.Diagram Cloud, text explicitly styled with Arial renders in a fixed-pitch/serif-numeral font (visually consistent with Courier New — e.g. the digit “1” has a foot serif, which Arial’s does not) instead of Arial or any reasonable substitute. PdfSaveOptions.DefaultFont has no observable effect on this, under any value or font source we’ve tried.

Steps to reproduce

  1. PUT /diagram/storage/file/{name}.vsdx — upload a .vsdx containing shapes styled with Arial.
  2. POST /diagram/{name}.vsdx/saveAs?newfilename={name}.pdf&IsOverwrite=true with body:
    {
  "FileName": "{name}.pdf",
  "Format": "pdf",
  "SaveOptions": { "SaveFormat": "pdf", "DefaultFont": "Arial" }
}
  3. GET /diagram/storage/file/{name}.pdf — download the result.
  4. Observe: Arial-styled text is rendered in a fixed-pitch font, not Arial.

What we’ve already ruled out

  • The stateless endpoint (PUT /diagram/{name}/convert) can’t carry save options at all. Appending any second multipart part (e.g. a SaveOptionsData JSON part, mirroring the pattern documented for Aspose.Words Cloud’s online endpoints) fails outright:

    HTTP 500 {"error":{"code":"internalError","message":"Expected only one part in the MIME multipart request."}}

    So no font/save-option control is possible through that endpoint under any approach.

  • SaveOptions on the saveAs endpoint is genuinely parsed and applied — this isn’t a silent-ignore issue. Setting SaveOptions.Compliance to "PdfA1b" / "PdfA1a" produces a materially different, correctly-conformant PDF each time (confirmed via %PDF-1.4 header vs. %PDF-1.5 baseline, larger file size from full font embedding, and genuine pdfaid:conformance/pdfaid:part XMP metadata and /OutputIntents matching the requested level). This proves the request body is correctly deserialized and acted on by the endpoint.

  • DefaultFont itself never changes the output, tried as:

    • "Helvetica" (a standard PDF font, guaranteed available without embedding)
    • "Arial", with the actual Microsoft Arial.ttf (from a licensed Windows install) uploaded to the same Fonts folder, replacing the substitute

    Both produced pixel-identical fallback output to the baseline with no DefaultFont set at all.

Questions

  1. Is PdfSaveOptions.DefaultFont intended to affect substitution for a named-but-unresolvable font (e.g. a shape explicitly styled “Arial” where Arial isn’t installed on the render host), or only for characters with no font assigned?
  2. Does Aspose.Diagram Cloud support a custom-fonts mechanism analogous to the storage Fonts folder used by Slides/Words/Imaging/Cells Cloud? Our testing suggests it does not consult that folder at all for either name-based resolution or DefaultFont fallback.
  3. What font, if any, does Aspose.Diagram Cloud’s Linux render host actually have installed for a plain sans-serif family, and is there any supported way (SaveOptions field, account setting, or otherwise) to point Visio-to-PDF conversion at a specific font for text whose original font isn’t available server-side?
2

@mesindesign
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): DIAGRAMAPP-3352