#29886

There is no pd4browser.properties yet.
I also successfully tried running older versions (such as 380fx2, 380fx3) from the same location with the same JVM – these run.

#29884

Thank you for investigating the problem and your response. Obviously it’s not absolutely necessary to have folders starting with the dollar sign, though it’s my habit and I simply haven’t expected that to be the cause of this (or any) NPE.
From my point of view, any legal paths may as well be handled correctly.

Unfortunately renaming that folder doesn’t seem to work, even after renaming the folder and, in subsequent attempts, trying to start it from within the folder or moving the folder to a very short path with no objectionable characters in it, it still crashes:

c:tempvakkk>java -Xmx1024m -jar pd4ml.jar
java.lang.NullPointerException
at java.io.File.<init>(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.o00000(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.<init>(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.showGUI(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.main(Unknown Source)

which keeps puzzling me.
Now I was testing with the version 399fx1.

Could the issue be another one?

UPDATE: I have tested some more, tried to run other (older) JVMs and the exception seems to be the same with all of them:

c:tempvakkk>jrockit-R27.6.3-jre1.5.0_17binjav
a.exe  -Xmx1024m -jar pd4ml.jar
java.lang.NullPointerException
at java.io.File.<init>(File.java:194)
at org.zefer.pd4ml.tools.PD4Browser.o00000(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.<init>(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.showGUI(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.main(Unknown Source)

c:tempvakkk>jdk1.6.0_25jrebinjava.exe  -Xmx1024m -jar pd4ml.jar
java.lang.NullPointerException
at java.io.File.<init>(File.java:222)
at org.zefer.pd4ml.tools.PD4Browser.o00000(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.<init>(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.showGUI(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.main(Unknown Source)

c:tempvakkk>jdk1.7.0_40jrebinjava.exe  -Xmx1
024m -jar pd4ml.jar
java.lang.NullPointerException
at java.io.File.<init>(File.java:277)
at org.zefer.pd4ml.tools.PD4Browser.o00000(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.<init>(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.showGUI(Unknown Source)
at org.zefer.pd4ml.tools.PD4Browser.main(Unknown Source)

#29197

Sorry for late response.
The patched version seems to be immune to the problem now.
Thank you!

#29196

Thank you a lot! I need to forward that and wait for it to be available for testing, but will get back to you as soon as we could deploy & test it.

#29194

Since the hack is what it is – a CSS hack meant to be ignored – and we do not want to play MSIE, I do not think there is any need or a way to try to parse that value. It should just be “safely ignored” as it is in non-MSIE browsers.

So I think catching that exception and throwing away that one property would be all that’s needed. Could this be done by you, or is that already something in the library?

On a side note: it’s not “0px9” what causes the exception – that value goes through. It’s that without an unit – “09” where the “9” gets parsed as part of a number – that crashes it.

#28815

The positioning issues are solved for me in that version, thank you so much for the quick response!
Also thank you for the PD4ML console/GUI, it makes it so much easier to debug HTML without having to generate a PDF every time. You may want to advertise it more 🙂

I have found another issue involving rather tricky LIs with bullet-dots coded as background, some positioned to the left, some to the right. I’ll start a new thread about that as soon as I have a clearer description of the issue and an isolated testcase.

#28813

@mackelito wrote:

Has there been a new release with this feature added?

A look at the download page has the answer. Still 380fx2, tagged with a date before this discussion.
[Not that I wouldn’t have liked the answer to be different though :)]

#28691

@PD4ML wrote:

Viktor,
Could you please create and send us an HTML document, with your most wanted currently unsupported CSS features we could use for our internal tests?
(including html-css-to-pdf-rendering-issues-f3/absolute-positioning-within-a-padded-parent-t524.html test case)

Hello – thank for your reply.
Our currently most wanted properties are those 2 remaining positioning directions – bottom and right, and the already referenced “padding in absolute positioning parent” issue.
I have created another test case that tests both these issues:
http://www.vergangen.de/permatemp/pd4mlreport/pd4mltest_positioning.html
It needed a bit of overhead for MSIE, but in the end it shows the same in all browsers and, ideally, it should show the same in PD4ML. Testing in the GUI of the last version, all the violet boxes show overlapping at one position, while they should be occupying the respective corners of the parent box.

Kind regards,
Viktor

#28834

@PD4ML wrote:

Few minutes ago I replied to another your question and referenced the issue as well.

Ah, sorry and thank you. We must have been writing simultaneously.
I’ll put one together and post it ASAP.

Thank you and have a nice evening from freezing Munich!

#28832

@vk_iconparc wrote:

Ping. Any idea on this, anyone? 🙂

Sorry to have to do this – but is there any response to this from the authors?

#28831

Ping. Any idea on this, anyone? 🙂

#28689

I add my “want” vote as well. Please! 🙂
In my case it’s “right:” that we’re sorely missing.

#28807

Hi Kalle,
it depends on what you call “inheritance”. I believe we’re looking at a double-class selector issue here.

That kind of selectors is generally not robust, as MSIE – for example – doesn’t evaluate them correctly either.
In MSIE, a selector like .class1.class2 {} will be evaluated as .class2{} – all elements with the class class2 will be influenced.
Likewise, in PD4ML it seems to be the first class that gets honored.

So, in my opinion, the question of your post is: does PD4ML support double-class selectors?

And a robustness hint is: try to avoid them as they’re problematic with browsers as well (at least to my experience).

HTH,
Viktor

#28003

Was the problem known already?

Anyhow – that’s good news, thank you. Any idea of the estimated release date?

#27852

First, thank you very much for your quick reply. The code is being run on mightysite.dom itself and it is known to itself. The problem shouldn’t originate there. Images, for example, are being downloaded fine.

As for the debug info, that is a slight problem, because the PD4ML library is being used internally by our own module, so it’s one level too depp for me. Can’t easily access and modify PD4MLs properties. I’ll see what I can do.

So, in principle, you say that the external stylesheets should work…right?

[Author]

Posts