#41935

Hello,

thank you for the sample. A few observations:

1. The sample does not seem to be a font-metrics problem. It uses font-family: Arial with a table that combines rowspan, colspan and fractional percentage widths (72.4053%, 64.5636%, 57.5132%, 79.3618%). The 4.0.24 release (and 4.1.2) fixed several table layout problems of exactly this kind:
– colspan cells over fixed-width columns no longer overlap or clip their content, because their minimum width is now distributed over the spanned columns
– fractional percentage widths such as 4.0002% are applied exactly instead of being rounded
– rowspan height distribution was corrected

Please try the sample with v4.0.24 (or v4.1.2 if you are on the 4.1 line). If the text is still clipped there, please tell us the exact version you tested, the font directory you used and your PD4ML setup code. With that we can reproduce it.

2. OpenType (.otf) fonts with CFF outlines are supported since v4.0.23fx2. Since v4.0.24 and v4.1.2 they are also embedded as a subset, so the PDFs stay small. Conversion to TTF is not needed. If your OTFs did not work in an earlier 4.x build, please retry with a current one.

3. Font setup, for reference:

PD4ML pd4ml = new PD4ML();
pd4ml.useTTF("/usr/share/fonts/truetype/noto", true); // directory is indexed; true = embed
pd4ml.setDefaultTTFs("Noto Sans", "Noto Sans", "Noto Sans Mono");

In the CSS, use the font family name that the font itself reports, for example font-family: "Noto Sans". Otherwise the text falls back to the built-in Helvetica, whose widths differ from the embedded font. Also check that regular, bold, italic and bold italic files of that family are all in the indexed directory.

You can also pass a name filter to useTTF() to index only the files you need. That avoids picking up the thousands of other fonts on the system.

Best regards,
PD4ML Support

#41934

Hello Palle,

Good to hear the fix works for you.

Regarding v3: no, the v3 line does not have the automatic jakarta/javax switching. The automatic compatibility with both frameworks was introduced in the v4 line, in v4.0.21. The v3 jar is built against javax.servlet only. The release notes don't list any jakarta support for v3, so I can't offer you a jakarta build of it.

The v4 jar still contains the v3-style API (the org.zefer.pd4ml package), so existing v3 code often works against v4 with little or no change. If your tiles setup depends on v3 only for API compatibility, I'd suggest trying v4 as a drop-in replacement. If something doesn't work after the switch, please post the error or stack trace and we'll look at it.

One more thing about the font fix. The release notes list the unique font subset tag fix (HELPD-848) under v4.0.24 (2026-10-17) and v4.1.2 (2026-10-17). They don't list it for v3. If you stay on v3 for tiles, the duplicate subset prefix problem may still be there. You may want to move to a current v4 release, which would also solve the jakarta question.

Best regards,
PD4ML Support

#41933

Hello Andrea,

Sorry that this has been open for so long. Did the email exchange with us work out in the end, either through your CFO or through your personal address? If it did, is the email address on your license now updated?

If it's still open, please tell us here. We'll look at the transfer form error and at why your emails didn't reach us. It would help if you could send:
– the exact text of the error page, or a screenshot with any personal data hidden
– the approximate time you submitted the form
– the address you used to write to us, so we can check our mail logs and spam filters

Please don't post your serial number or email address in the forum.

As we said earlier, the change of the account email doesn't affect existing installations. They keep working the same way.

Best regards,
PD4ML Support

#41932

Hello,

Maven doesn't take repository credentials from pom.xml. They have to go into your settings.xml, in a [server] entry whose id is exactly the same as the id of the repository in your pom. A mismatch is the most common reason for "dependency could not be resolved" (401/403 or "not found").

1) ~/.m2/settings.xml (use the username and password from your license e-mail):

<settings>
  <servers>
    <server>
      <id>pd4ml</id>
      <username>YOUR_USERNAME</username>
      <password>YOUR_PASSWORD</password>
    </server>
  </servers>
</settings>

2) pom.xml (use the repository URL from the manual or your license e-mail. The URL below is only a placeholder, so replace it with yours):

<repositories>
  <repository>
    <id>pd4ml</id>
    <url>REPOSITORY_URL_FROM_YOUR_LICENSE_EMAIL</url>
  </repository>
</repositories>

3) Force Maven to retry. Failed lookups are cached, so run this:

mvn -U clean compile

If you work in Eclipse, also use Maven > Update Project with "Force Update of Snapshots/Releases" ticked.

Please also check these:
– The artifact version in your dependency matches a version that exists in the repository. Your maintenance is valid until 2027-01-16.
– Your build doesn't use a mirror with mirrorOf set to "*" in settings.xml. It would redirect the PD4ML repository to another server. Use mirrorOf "*,!pd4ml" instead.
– The username and password have no typos, and special characters in the password are XML-escaped.

The activation key is separate from Maven. It isn't used for downloading. It goes into the pd4ml.lic file, which must be in the application working directory or at the classpath root.

If it still fails, please post the exact error from "mvn -U -X" (remove the password), your dependency and repository sections, and the PD4ML version you want to use. Then we can see where it breaks.

Best regards,
PD4ML Support

#41931

Hello sivanleoni,

Just to clear up one point: PD4ML does support https. Images, CSS and other resources are loaded over https by the library itself, and it doesn't validate the server certificate. You don't need a custom resource loader for this. So the cause is almost certainly in the runtime environment, not in PD4ML.

You said it works from the command line with the same JRE, but not from ColdFusion. That points to something inside the ColdFusion process. Typical causes are:
– ColdFusion has its own security settings or TLS provider jars (for example an old or bundled JSSE or Bouncy Castle) that differ from the plain JRE.
– The image server has dropped older TLS versions or cipher suites, and the Java inside ColdFusion can't negotiate a new enough one. This usually happens after the server's certificate or TLS configuration is renewed, which would explain the sudden failure after years. Updating ColdFusion's bundled Java (or pointing ColdFusion at a current JDK) normally fixes it.

To see the actual error, enable PD4ML logging before readHTML():

<cfscript>
pd4 = createObject("java", "com.pd4ml.PD4ML");
Constants = createObject("java", "com.pd4ml.Constants");
pd4.setLogLevel(Constants.LOG_VERBOSE);
// ... readHTML / writePDF as before
</cfscript>

The messages go to the console, which for ColdFusion is its output log (coldfusion-out.log). Please post the lines mentioning the failed https image. They will name the exact cause, for example a handshake failure, "protocol_version", "Could not generate DH keypair" (the message PD4ML prints when the Java libraries are too old), or a timeout.

Two quick checks:
1. Run java.lang.System.getProperty("java.version") from inside ColdFusion, and compare it with the CLI JRE. The "same runtime" may not be the one ColdFusion actually uses.
2. Check whether your jar is the latest build available to you. Your maintenance period ended on 2026-03-23, so newer releases may not be covered by it. Please contact us about renewal if you need one.

As a workaround, if you can't fix the TLS setup right away, keep the images on http or embed them as data: URIs.

Please send the PD4ML version (the jar file name is enough) and the log output, and we'll look further.

Best regards,
PD4ML Support

#41930

Hello,

Sorry for the long wait. The behavior you describe (a footnote moving to the next section's page when the last page of a section is full, and ifSpaceBelowLessThan having no effect before an explicit page break) was a bug. It is fixed in release v4.0.24 (17 Oct 2026): ifSpaceBelowLessThan is now honored on pages that end with an explicit page break, so the footnote no longer lands on the next section's page.

The same fixes are in v4.1.2 if you prefer the 4.1 line. v4.1.1 and v4.1.2 were released after your post, so the note that the footnote changes were not yet in 4.1.x no longer applies.

Please try 4.0.24 or 4.1.2 with your original markup:

<pd4ml:page.break ifSpaceBelowLessThan="200px"/>
<pd4ml:footnote noref>…</pd4ml:footnote>
<pd4ml:page.break/>

You can then drop the empty <p></p> workaround. Your serial ZF8900.320484.377182.1 has maintenance until 2026-12-05, so these versions are covered.

v4.0.23fx2 also fixed a "noref footnote right before a page break is printed on the next page" case. Your 4.0.23 test may have missed it, which is another reason to retest on the current build.

Variant 2 (the same footnote at the bottom of every page of a section): pd4ml:footnote is printed once, where it occurs, so it can't repeat on each page. For that pattern, define the section text as a page footer instead. Each section would redefine <pd4ml:page.footer>, and the redefinition applies from the page where it is defined. That behavior was also corrected in 4.0.24. Please test it with your sections. If the first page of a section still shows the previous footer, send us a minimal HTML sample and your exact PD4ML version, and we'll look at it.

If the problem remains on 4.0.24 or 4.1.2, please attach a minimal HTML that reproduces it.

Best regards,
PD4ML Support

#41929

Hello Tom,

Since v4.0.21 there are no separate -jakarta and javax builds any more. The release notes for that version say the separation between the jakarta and javax versions ends, and the library works with both. So the standard jar is the right one for WildFly 32, and you don't need a separate "-jakarta" download. This also covers the 4.0.20fx3-jakarta and 4.1.0 requests earlier in this thread. The wording on the download page is outdated, and I'll pass that on.

You don't need an environment flag either, and I don't see one in the code. PD4ML tries the javax and the jakarta servlet resource providers one after the other. A provider whose servlet API isn't on the classpath is skipped. On WildFly 32 only the jakarta classes exist, so the javax ones can't load there and are simply ignored. When you pass the request and response, use the Jakarta objects:

PD4ML pd4ml = new PD4ML(); // jakarta.servlet.http.HttpServletRequest / HttpServletResponse are accepted pd4ml.useHttpRequest(request, response);

If you see an actual error or a failing conversion, and not just a javax class name in a log or trace, please send me:
– the exact PD4ML version (4.1.1?),
– the full stack trace or log output,
– how you call PD4ML (the servlet, the JSP taglib, or standalone code).

That will show which class is really failing.

Best regards,
PD4ML Support

#41686

Hello! We replied in the HELPD-853 thread back in August and were awaiting your feedback, as the issue appears to be primarily related to the CF configuration. Could you please perform some minimal testing of the suggested options to help pinpoint the root cause of the problem?

Obviously one of the ColdFusion tags implicitly opens the HTTP output stream and writes to it, whereas all nested tags are expected to write data that forms the body content of the enclosing pd4ml tag. You can remove the CF tags or blocks one by one to narrow down to the problematic elements. We suspect it is <cfoutput> . Or perhaps the loop generates too much output, causing the buffer to be flushed to the HTTP channel.
If the JSP page using PD4ML and CF works in other environments, we hope there is a configuration that prevents CF tags from immediately initiating the HTTP response write.
AI provides some hints like <cfsetting showdebugoutput=”false”>, <cfcontent reset=”false”> or to significantly increase CF output buffer. But right now we can’t test these proposals.

#41670

Hi Sam, Stripe is an online credit card payment provider that doesn’t require you to create an account. Just select the Stripe option and pay with your credit card as usual.

#41484

Hi! The issue was initially resolved in version v4.0.23fx1, and the fix was subsequently ported to version v4.1.1-SNAPSHOT.

v4.0.23fx1 is currently in “released” state, so it is recommended for production. v4.1.1 is going to be released only in 7-10 days.

Both version should switch automatically between jakarta and javax depending on runtime environment.

#41369

Hi, Palle! We apologize for the communication issues you’ve experienced. Did you not receive a response regarding ticket HELPD-848? We are working on resolving this; a fix is ​​scheduled for the upcoming build, which is due out in about a week.

#41341

In rare cases, we need to manually initiate an update of the SHA access codes. We apologize for the inconvenience.

#41340

In fact, the correct way to set the color is using the ::marker pseudo:

ol li::marker {
    color: red;
}
ul li::marker {
    color: purple;
}

However, surprisingly this doesn’t work either.

We’ll fix the issue with the forthcoming patch level build

#41204

As we can see, all notification emails go to Jeff’s email.
To simplify things, please send an email to helpdesk pd4ml com (with all other request participants in CC, if any), so we do not need to manually create new user accounts. Thank you!

#41186

BTW, have you received the helpdesk message with the additional info request?

[Author]

Posts