#28883

Since one of the recent versions, there is a bug in our code. In some situations it does not compress image bytes. Most probably you faced with the effect.

The issue is already solved and we are almost ready to release an updated version. Currently the new build is under QA. If everything is ok, we’ll release the version later today.

#28884

Thanks. That was fast!

So there is nothing that we need to think about in order to produce a smaller PDF? We’ll just update to the next version and we should be good to go?

Regards, Jon

#26685

We are running a PD4ML Pro 323, which I am aware of is a bit old. Lately we had an incident where arbitrary requests/responses were mixed up, that is users seeing each other’s data! Being a web application that requires login and uses HTTPS to protect our user’s data that is very serious business. The problem was traced back to our usage of PD4ML.

PD4ML.render(StringReader, OutputStream) was called from a web application, and HttpServletResponse.getOutputStream() was used as the second argument. It turns out that PD4ML closes the OutputStream, and does it twice. Once from within PD4ML.render() via PD4Device.dispose(). That is unexpected (since the usual contract is that the one who opened a stream is the one responsible for closing it), but it does not do any harm in our case. The second close comes from PD4Device.finalize(), and that is the harmful one! The finalize method will be invoked from another thread, the JVM FinalizerThread, at some later time in the future. It means that the ResponseOutputStream gets an unexpected close() call from an external thread, which is not allowed by the Servlet specification.

We are using Apache + Tomcat with an AJP connector. In that case, the OutputStream returned by response.getOutputStream() is a org.apache.catalina.connector.CoyoteOutputStream, which is a thin wrapper dispatching directly to an org.apache.catalina.connector.OutputBuffer. The problem is that the latter is reused by the web container. So when the stream.close() comes from PD4Device, it is probably already pooled for reuse or even in use by a subsequent request! That unexpected close causes the connector and/or Apache mod_jk to mismatch request/response on that socket. Exactly how this bit happen has not been possible to debug yet. But clearly the web container makes no guarantees if the response stream is accessed out of scope.

If I wrap the ServletOutputStream with a FilterOutputStream that makes all close() calls ignored, the bug disappears at once. That is how the call from finalize was found.

at org.zefer.pd4ml.pdf.PD4Device.dispose(Unknown Source)<br /> at org.zefer.pd4ml.pdf.PD4Device.finalize(Unknown Source)<br /> at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)<br /> at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:101)<br /> at java.lang.ref.Finalizer.access$100(Finalizer.java:32)<br /> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:178)

Why would you close a stream in finalize()? A stream that you did not even open and thus were not responsible for closing? I know there are several releases past 323, but since we are currently not paying for updates I can’t tell if the bug remains or not. If it does it should be fixed, or you must post big warning signs in the javadoc that no one must ever call PD4ML.render() with a ServletOutputStream as argument.

#28885

right.

#26686

Hello everyone

The infomation blow is from my pd4ml.jar

Manifest-Version: 1.0
Class-Path: ss_css2.jar
Ant-Version: Apache Ant 1.6.5
Created-By: yGuard Bytecode Obfuscator 2.0.1
Main-Class: org.zefer.pd4ml.tools.PD4Browser
Implementation-Title: PD4ML Pro
Implementation-Version: 310b10

Does this version lib support “border-collapse: collapse;” property?

whatever I test, with “border-collapse: collapse;” or “border-collapse: separate;”
in CSS file, it doesn’t affect table border in the PDF I generate.
It always looks as “border-collapse: separate;”.

Could anyone help confirm if this version lib can work well with “border-collapse” property or not.

thanks

#28894

border-collapse: collapse is supported since v3.21, however a correct table break (by a page break) with the style is applied is implemented in v3.80b1.

Your version definitely does not support the feature.

#28891

The issue has been solved in the actual versions of PD4ML. Just give a try to any fully-functional evaluation version (or request a commercial one to evaluate from support pd4ml com).

> usual contract is that the one who opened a stream is the one responsible for closing it

You are right. But if we leave the output stream not closed, there is a probability the hosting framework writes some finalizing content/tags there, which corrupts the generated binary PDF data.

A safer (and recommended) approach would be to pass ByteArrayOutputStream to render() method. That would also let you measure generated PDF size and send correct Content-length HTTP header.

#28892

So the stream.close() is now definitely removed from the finalizer, is that correct? Do you know in which release this was fixed? Any release note link?

I’ll give the evaluation jar a spin in my local environment and see how it acts. Thanks.

#28893

Currently PD4Device.finalize() looks like that:

[language=java:yltto70d]/**
* @see java.lang.Object#finalize()
*/
public void finalize() {
// dispose();
}[/language:yltto70d]

Unfortunately I could not find in our source control system when exactly the dispose() call has been commented out. But it definitely happened more that 2 years ago.

dispose() method is triggered once now. The method forces collected PDF metadata to be written and it still closes the output stream.

I would recommend to wait the next 2-3 hours – we plan to get from QA and to release the newest version today. Of you can get it on Monday.

#28853

Unfortunately we have to leave the issue as it is. A workaround requires a significant refactoring of the table break logic.

Hopefully the solution with style=”border-collapse: separate” works for you.

#26687

Hello,

We are using pd4ml.pro.trial.380fx2.zip to generate the pdf file from HTML pages. The tool is working great but the time taken to generate the file with css is too long. If we do not apply css on our pages, the time is not too much but if the HTML contains images and css is applied on it, the time taken to generate the pdf file is too high. We are generating pdf fore more than 50 pages having images in it.

Can you please suggest is there any possible way to decrease the render time or it’s a known issue?

#28895

If the CSS stylesheet is linked as a external resource and it impacts the performance, first I would suspect network delays/routing issues by the CSS loading.

Also try to add a simple progress monitor to determine at which conversion phase the delay occur: http://pd4ml.com/cookbook/html_pdf_conversion_progress_monitoring.htm

#28854

Unfortunately style=”border-collapse: separate” didn’t work. Had to create another

in the

tag. We can close this issue.

#28886

@PD4ML wrote:

The issue is already solved and we are almost ready to release an updated version. Currently the new build is under QA. If everything is ok, we’ll release the version later today.

I guess the fix for this has not been released yet, any new information on when it will be available?

Thanks, Jon

#26684

Hi,

We have a requirement in our project to generate a pdf report with the list of some data and each data entry has an image associated with it.

When we try to generate a PDF from HTML using the PD4ml library with say 1000 data objects with each data entry having an image of size 50 KB, then we start running out of Heap memory with the below mentioned trace.

<br /> Exception in thread "Image Fetcher 2" java.lang.OutOfMemoryError: Java heap space<br /> at java.awt.image.DataBufferInt.<init>(Unknown Source)<br /> at java.awt.image.Raster.createPackedRaster(Unknown Source)<br /> at java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)<br /> at sun.awt.image.ImageRepresentation.createBufferedImage(Unknown Source)<br /> at sun.awt.image.ImageRepresentation.setPixels(Unknown Source)<br /> at sun.awt.image.ImageDecoder.setPixels(Unknown Source)<br /> at sun.awt.image.JPEGImageDecoder.sendPixels(Unknown Source)<br /> at sun.awt.image.JPEGImageDecoder.readImage(Native Method)<br /> at sun.awt.image.JPEGImageDecoder.produceImage(Unknown Source)<br /> at sun.awt.image.InputStreamImageSource.doFetch(Unknown Source)<br /> at sun.awt.image.ImageFetcher.fetchloop(Unknown Source)<br /> at sun.awt.image.ImageFetcher.run(Unknown Source)<br /> <br />

I have my JVM Max heap configured to 1GB. Is there some way we can handle such large number of images in PDF report without exhausting the Heap.

regards,
Mayur

[Author]

Posts