#28454

why the support is very slow

#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.

#28436

In the actual development branch (and in v370fx2) the method is implemented safe way.

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) {
}
}
}

(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.

#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

#28438

To generate a table of contents (only if the doc has <pd4ml:toc> 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.

#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

#28457

Is it marked as supported?

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

(which matches the current functionality)

#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

#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).

#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

#28439

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

#28461

Yes, the evaluation version will be illustrative.

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

#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.

#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

#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.

[Author]

Posts