Forum Replies Created

Viewing 15 posts - 1,726 through 1,740 (of 4,243 total)
  • Author
    Posts
  • in reply to: How to optimize the size of the generated PDF?
    #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.

    in reply to: How to optimize the size of the generated PDF?
    #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

    in reply to: Troubleshooting
    #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.

    in reply to: How to optimize the size of the generated PDF?
    #28885

    right.

    in reply to: HTML/CSS rendering issues
    #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

    in reply to: question for pd4ml using CSS
    #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.

    in reply to: PD4Device.finalize() closes output stream and causes mixup!
    #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.

    in reply to: PD4Device.finalize() closes output stream and causes mixup!
    #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.

    in reply to: PD4Device.finalize() closes output stream and causes mixup!
    #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.

    in reply to: Table cell border not drawn after page break
    #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.

    in reply to: General questions / FAQ
    #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?

    in reply to: pd4ml.render is taking too long time
    #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

    in reply to: Table cell border not drawn after page break
    #28854

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

    in the

    tag.

    We can close this issue.

    in reply to: How to optimize the size of the generated PDF?
    #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

    in reply to: General questions / FAQ
    #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

Viewing 15 posts - 1,726 through 1,740 (of 4,243 total)