PdfTrueTypeFont constructor fails

[mirko.golfieri]

Subject: PdfTrueTypeFont constructor fails with "CreateProcess error=5, Access Denied" when running as a Windows Service (cmd.exe spawn blocked)

We're using Spire.PDF for Java version 11.6.2 on Windows. We ran into a startup failure when initializing PdfTrueTypeFont instances eagerly inside a Servlet's init() method (running under Apache Tomcat installed as a Windows Service, via Procrun, account = Local System).
Error observed:
class com.spire.pdf.packages.sprmyj: Fail to save. Saving of requested font type is not supported.
...
class com.spire.pdf.packages.sprjbw: Cannot run program "cmd.exe": CreateProcess error=5, Access Denied
---> java.io.IOException: Cannot run program "cmd.exe": CreateProcess error=5, Access Denied
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1170)
at java.base/java.lang.Runtime.exec(Runtime.java:366)
at com.spire.pdf.packages.sprjbw.spr...(Environment.java:362)
at com.spire.pdf.general.paper.drawing.ps.PsSystem.getWindowsFontsFolder(Unknown Source)
...
at com.spire.pdf.graphics.PdfTrueTypeFont.<init>(Unknown Source)
Root cause (confirmed from stack trace):

When constructing a PdfTrueTypeFont from a java.awt.Font instance (no explicit file path provided), Spire internally calls PsSystem.getWindowsFontsFolder(), which spawns an external cmd.exe process (via Runtime.exec) to determine the Windows fonts directory.
In our environment, the OS-level security policy / EDR blocks this specific service process from spawning cmd.exe, causing Runtime.exec to throw IOException: CreateProcess error=5, Access Denied, which Spire then wraps and propagates up, ultimately failing the PdfTrueTypeFont constructor entirely (no fallback).

Why this is a problem:

Spawning cmd.exe to resolve the Windows fonts folder is unnecessary — this information can be obtained without creating a child process (e.g. System.getenv("WINDIR"), registry access via JNA, or relying on java.awt.GraphicsEnvironment/font enumeration APIs that the JVM itself uses, which don't require spawning external processes).
Restricting child-process creation for Windows services is a standard, legitimate security hardening practice (enforced here by an EDR/AppLocker-type policy) — many enterprise/healthcare environments do this by default. A core PDF/font library shouldn't depend on the ability to spawn cmd.exe for basic font resolution.
There's no graceful fallback: when the cmd.exe spawn fails, the entire PdfTrueTypeFont construction fails hard instead of falling back to an alternative resolution method.

Environment:

Spire.PDF for Java: 11.6.2
JDK: 21.0.2
OS: Windows Server (Tomcat installed as Windows Service via Procrun, Local System account)
Reproduced with a minimal standalone test (no Tomcat, no other dependencies) running as a Windows Service under the same account — isolating the issue specifically to the cmd.exe spawn step in PdfTrueTypeFont initialization, not to our application code or to Tomcat/Servlet context. [se confermato domani: "and confirmed the failure reproduces identically in this isolated test"]

Request:
Could you confirm whether getWindowsFontsFolder() could be reimplemented without spawning cmd.exe, or whether a configuration option / fallback exists to avoid this child-process dependency? This would make the library usable in security-hardened Windows service environments where child process creation is restricted.
Happy to provide the full standalone reproduction project if useful.
Thanks!

PS: here a france link https://attack.mitre.org/techniques/T1190/

[amy.zhao]

Hello,

Thank you for your feedback.

For your specific scenario, we recommend loading fonts directly by specifying the absolute file path, rather than relying on system font enumeration. This approach bypasses the internal call to `cmd.exe` and avoids the access denied issue.

Please use the following code:

Code: Select all

// Load font directly using the absolute file path
PdfTrueTypeFont font = new PdfTrueTypeFont("C:\\Windows\\Fonts\\arial.ttf", 12f);

We hope this resolves your issue. Please let us know if you have any further questions.

Sincerely,
Amy
E-iceblue support team

[mirko.golfieri]

Hello.
Sorry for my late reply but I do not receive your answer by mail.
The solution proposed by you is not appliable. It make no sense that and application goes to read font from phisical path when exists Java native method to do it without security issue.

I have a question regarding the implementation of PdfTrueTypeFont(Font font).

Since this constructor accepts a java.awt.Font instance, I would expect the Font object itself to be sufficient.

However, from our investigation, it appears that Spire attempts to locate the physical font file by resolving the Windows Fonts directory and spawning cmd.exe.

Could you explain why the physical font file is required when a Font object has already been provided?

As far as I know, the standard Java API does not expose the underlying TTF file path, so the application cannot reliably provide this information itself. Therefore, suggesting the constructor that accepts a file path does not seem to address the original issue.

Please, follow my post and evaluate it to solve this security issue.

Mirko

[amy.zhao]

Dear Mirko,

Thank you for your detailed report.

We have confirmed this issue and addressed it in the latest release.The font resolution mechanismin PdfTrueTypeFont（Font) has been refactored to no longer depend on external processes.

Please upgrade to version 12.7.0 (https://www.e-iceblue.com/Download/pdf-for-java.html), which resolves this problem. No code changes are required on your side.

Please feel free to contact us if you have any issues.

Sincerely,
Amy
E-iceblue support team