Is this.pdf.type = "classic" supposed to work and compatible with ColdFusion?

I use Lucee and I need to generate pdf exactly as in ColdFusion 11, which I believe use iText.

The new Lucee engine seems to be different (fonts different, images not rendered, sizes), so I tried to set this.pdf.type = “classic”.

But still there are many differences and some pdf generation is simply failing (produce a file with wrong format, or gives errors on some image manipulation)

Anyone tried this? any guidelines?
I’ll try to come up with more specific errors.

Here a first problem:
I tried this simple file

<cfdocument localUrl="yes" format="pdf" orientation="landscape" unit="cm" pagetype="a4">
<img src="pdfimage.png" width="200">

With Coldfusion, the image is rendered.
With Lucee, either with this.pdf.type=“classic” or not, no image is shown

tried also with localurl=“no” and full http url, same result

it’s always a good idea to check jira for known issues

alas, PDF support in Lucee is still rather rough around the edges

I see…but I managed to make a virtual host work on the same machine.
Now this other virtualhost produces empty pdf…only thing I can see is this stackTrace.
And I checked the WEB-INF/lucee/fonts, should be ok

"ERROR","http-nio-8888-exec-37","01/30/2020","17:57:24","",";class sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont (sun.font.CompositeFont and sun.font.PhysicalFont are in module java.desktop of loader 'bootstrap');lucee.runtime.exp.NativeException: class sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont (sun.font.CompositeFont and sun.font.PhysicalFont are in module java.desktop of loader 'bootstrap')
	at java.desktop/sun.font.SunFontManager.getDefaultPhysicalFont(
	at java.desktop/sun.font.SunFontManager.initialiseDeferredFont(
	at java.desktop/sun.font.CompositeFont.doDeferredInitialisation(
	at java.desktop/sun.font.CompositeFont.getSlotFont(
	at java.desktop/sun.font.CompositeStrike.getStrikeForSlot(
	at java.desktop/sun.font.CompositeStrike.getFontMetrics(
	at java.desktop/sun.font.FontDesignMetrics.initMatrixAndMetrics(
	at java.desktop/sun.font.FontDesignMetrics.<init>(
	at java.desktop/sun.font.FontDesignMetrics.getMetrics(
	at java.desktop/sun.font.FontDesignMetrics.getMetrics(
	at java.desktop/sun.awt.SunToolkit.getFontMetrics(
	at java.desktop/sun.awt.HeadlessToolkit.getFontMetrics(
	at org.zefer.font.c.super(Unknown Source)
	at org.zefer.font.c.<init>(Unknown Source)
	at org.zefer.cache.ResourceCache.getFontMetrics(Unknown Source)
	at org.zefer.html.doc.q.Ó00000(Unknown Source)
	at org.zefer.html.doc.q.return(Unknown Source)
	at org.zefer.html.doc.w.<init>(Unknown Source)
	at org.zefer.html.doc.PD4MLHtmlParser.buildDocument(Unknown Source)
	at org.zefer.pd4ml.PD4ML.o00000(Unknown Source)
	at org.zefer.pd4ml.PD4ML.render(Unknown Source)
	at org.zefer.pd4ml.PD4ML.render(Unknown Source)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.base/java.lang.reflect.Method.invoke(
	at org.lucee.extension.pdf.pd4ml.PDFByReflection.invoke(
	at org.lucee.extension.pdf.pd4ml.PDFByReflection.render(
	at org.lucee.extension.pdf.pd4ml.PD4MLPDFDocument.content(
	at org.lucee.extension.pdf.pd4ml.PD4MLPDFDocument.render(
	at org.lucee.extension.pdf.tag.Document.render(
	at org.lucee.extension.pdf.tag.Document._doEndTag(
	at org.lucee.extension.pdf.tag.Document.doEndTag(
	at pdf.pdf_image_cfm$cf$
	at lucee.runtime.PageContextImpl._doInclude(
	at lucee.runtime.PageContextImpl._doInclude(
	at lucee.runtime.listener.ModernAppListener._onRequest(
	at lucee.runtime.listener.MixedAppListener.onRequest(
	at lucee.runtime.PageContextImpl.execute(
	at lucee.runtime.PageContextImpl._execute(
	at lucee.runtime.PageContextImpl.executeCFML(
	at lucee.runtime.engine.Request.exe(
	at lucee.runtime.engine.CFMLEngineImpl._service(
	at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(
	at lucee.loader.engine.CFMLEngineWrapper.serviceCFML(
	at lucee.loader.servlet.CFMLServlet.service(
	at javax.servlet.http.HttpServlet.service(
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(
	at org.apache.catalina.core.StandardWrapperValve.invoke(
	at org.apache.catalina.core.StandardContextValve.invoke(
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
	at org.apache.catalina.core.StandardHostValve.invoke(
	at org.apache.catalina.valves.ErrorReportValve.invoke(
	at org.apache.catalina.core.StandardEngineValve.invoke(
	at org.apache.catalina.connector.CoyoteAdapter.service(
	at org.apache.coyote.http11.Http11Processor.service(
	at org.apache.coyote.AbstractProcessorLight.process(
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.base/java.util.concurrent.ThreadPoolExecutor$
	at org.apache.tomcat.util.threads.TaskThread$
	at java.base/
Caused by: java.lang.ClassCastException: class sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont (sun.font.CompositeFont and sun.font.PhysicalFont are in module java.desktop of loader 'bootstrap')
	... 68 more

the question is also, it is possible to use iText like in CF (and maybe even paying the licence if necessary?).
I though that “classic” would do the trick.
This is really blocking

Lucee is running on a EC2 Linux AMI

and java version

/opt/lucee/jre/bin/java -version
openjdk version "11.0.3" 2019-04-16

I’m guessing your VM doesn’t have a desktop gui installed right? it’s headless right?

follow the links in this bug

could you add a note that you’re getting this with PDF as well to the task?

ok, I probably got rid of the
class sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont error, and I added the comment.
Images are still a problem though

The funny thing is that I have 2 virtual hosts on the same Lucee installation mapped to 2 Lucee Applications and one is working “more or less” fine, the other doesn’t and I can’t tell the difference

glad to hear your making progress! thanks for commenting in jira :slight_smile:

out of interest, does it make a difference which virtual host, aka context gets hit first after a restart?

hmmm no, I don’t think it matters.

I managed to render the image with localUrl=“no” and the image url.
Previously I didn’t realize that the url was not resolved on the server.

So it doesn’t seem to be really a PDF problem, rather the file is not found with localURL=“yes” on some hosts. With harcoded path, no path, or getTempPath()… no success.

The files are on the same EFS as the cfm page. Lucee is running on an EC2.
I don’t see however any weird in the logs. Maybe I don’t have logging enabled for pdf…

just had a quick squiz, don’t think there’s any logging in the pdf extension…

do you see any requests for the missing images from lucee in the webserver logs?

what file extensions do the images have? seems there’s some hard wired logic
to inline .jpg files as base64

We haven’t been able to make our applications produce PDF documents reliably with the new PDF engine. eg. <div style="position:absolute;top:100;left:200">some text</div> places text in the top left corner of the page. We’re still using PDF extension version and Java 8 in our applications to keep PDFs working.