Forum Replies Created

Viewing 15 posts - 1,141 through 1,155 (of 4,243 total)
  • Author
    Posts
  • in reply to: dir=rtl is not working
    #28454

    why the support is very slow

    in reply to: dir=rtl is not working
    #28455

    We need some time to estimate efforts and to find a timeframe when the feature could be implemented. I’ll let you know in 3-4 hours.

    Currently there is no workaround for the table column order issue.

    in reply to: Java 6.0_24b07 crashes while in finalize of PD4Device
    #28436

    In the actual development branch (and in v370fx2) the method is implemented safe way.
    [language=java:1d2yehr4]public void dispose() {
    if ( this.pdfWriter != null ) {
    this.pdfWriter.close();
    this.pdfWriter = null;
    }

    if ( this.outputStream != null ) {
    try {
    this.outputStream.close();
    this.outputStream = null;
    } catch (IOException e) {
    }
    }
    }[/language:1d2yehr4]
    (I removed a couple of debug output lines)

    But I do not believe a repeating output stream closing may cause VM crash.

    As I wrote in the previous post, it crashes by an attempt to instantiate a color profile, extracted from an PNG image. The color profiles are handled by a native DLL, whose error crashes the JVM.

    in reply to: Java 6.0_24b07 crashes while in finalize of PD4Device
    #28437

    I think, not the output stream is the problem but the instance of class “c” , which is actually a PrintWriter.
    see:
    j org.zefer.pd4ml.pdf.c.close()V+12
    j org.zefer.pd4ml.pdf.PD4Device.dispose()V+23
    If you have a look onto the stacktrace:
    The finalyzer thread calls the finalyze/dispose method. Why will the c.close() method be called at all. The reference to the pdfWriter instance is or should at least be null, because the dispose method must have been called at the end of the render method of the PD4ML class.
    Could it be that there are more than one instance of PD4Device in use?
    Kindly
    Lutz

    in reply to: Java 6.0_24b07 crashes while in finalize of PD4Device
    #28438

    To generate a table of contents (only if the doc has tag), PD4ML creates a fake PDF device to predict page break positions. The device instance is disposed by finalize() method. It looks like the stack trace is produced by finalizing of the fake device.

    in reply to: dir=rtl is not working
    #28456

    thank you for your reply
    but i think you should remove it from the list of supported Html list cause its not fully supported and that is misleading just as what happened with me . also i will wait for your reply and i hope you have good news

    thank you very much

    in reply to: dir=rtl is not working
    #28457

    Is it marked as supported?

    It is only mentioned by tag reference, and tells:
    dir=”direction for weak/neutral text”

    (which matches the current functionality)

    in reply to: dir=rtl is not working
    #28458

    ok thank you . but please update me on when its gonna be implemented to change the direction for columns so that i can decide weather i should look for options other than PD4ML or wait for PD4ML

    thank you

    in reply to: dir=rtl is not working
    #28459

    The table column order switch is going to be implemented with the next maintenance release (in about one week). “List bullets/numbers right side” is probably too.

    We expect some minor issues to remain (however solvable with HTML coding workarounds).

    in reply to: dir=rtl is not working
    #28460

    thank you

    so you mean i will get an evaluation release in about one week that supports dir=”rtl” and specially column reordering which i can evaluate before i buy the library .

    if nothing more than one week from now then i will wait . please confirm

    thank you

    in reply to: Java 6.0_24b07 crashes while in finalize of PD4Device
    #28439

    What can we do to get rid of this? Can you please create a patch?
    Kindly
    Lutz

    in reply to: dir=rtl is not working
    #28461

    Yes, the evaluation version will be illustrative.

    If you want to test an interim build contact support pd4ml com on Monday

    in reply to: Java 6.0_24b07 crashes while in finalize of PD4Device
    #28440

    In one of the previous posts I asked you to try to identify the image, which crashes the VM. It would help us to find a solution.

    If it happens with any PNG image, it is definitely a inconsistency/configuration problem of your JDK.

    In any case we have a possible workaround: to (conditionally) disable color profiles extraction. But it would be better to avoid that.

    in reply to: Java 6.0_24b07 crashes while in finalize of PD4Device
    #28441

    The only picture we have inside the toc is the one I attached to this posting.
    But I think that the picture is not the problem because we get the pdf document without error.
    And my analysis showed that between the the download of the pdf and the crash were roundabout 50 minutes. So I think that the problem lies in the fact that the PD4Device with its related java resources were kept for that time frame, but the related native resources (profile data) were gone.
    I would suggest to dispose the second PD4Device too.
    Kindly
    Lutz

    in reply to: Java 6.0_24b07 crashes while in finalize of PD4Device
    #28442

    > between the the download of the pdf and the crash were roundabout 50 minutes

    Ok, now the picture is a bit more clear for me. So it looks like JVM releases resources, allocated by native DLLs, before the Java class is actually garbage collected. It is strange that the garbage collecting makes that long pause – on the other hand the Java spec does not limit the time.

    Next week we plan to release an updated version – we’ll add a workaround for the issue.

Viewing 15 posts - 1,141 through 1,155 (of 4,243 total)