Oxygen XML Forum

Running transformation scenario DITA Map Webhelp Responsive gives Nullpointerexception Cannot read field "result" because "fi" is null. Oxygen version 24.0, DITA OT version 3.6.1.
I saw some old posts on this subject, and based on those I checked that we don't have any file names with square brackets AND apostrophes. So there must be something else that triggers this exception.
One post reply said that the problem with brackets and apostrophes was fixed in DITA OT 3.7, not sure if our particular problem is also fixed in 3.7. We have quite a long process for upgrading to a later version, so all tips, outside of upgrade, are much appreciated. Our workaround now is to temporarily go back to version 21.0 of Oxygen, where we don't get this error, for each transformation.
thanks, Mikael

Hi Mikael,

As you mentioned you are currently using the veersion 24.0 of Oxygen, which comes with DITA OT 3.6.1 and, as you also figured out, some DITA Open Toolkit issues were fixed in the newer version 3.7 (which is the officially supported DITA OT with the minor version 24.1 of Oxygen), the first thing you should try would be to download and install the latest version of Oxygen software available on our website and use it with the DITA OT 3.7, then try running the WebHelp transformation scenario and see if the issues still occur.

If you still encounter issues, even when using the latest version of Oxygen and the DITA-OT 3.7, to investigate further, we need you to sent us (either directly, on support@oxygenxml.com) or through the online support form on our website, a complete DITA Map files hierarchy, in an as minimal form as possible, that we could use to reproduce the issues, along with a description of the issues you encountered.

Regards,
Costin

I upgraded to Oxygen v 24.1 and I can see that DITA OT v. 3.7.0 is used, but I still get the same result: transformation fails with error Cannot read field "result" because "fi" is null.. I will try to provide samples for troubleshooting as you instructed.
In the meantime, another related question: in the list of transformation scenarios we have DITA Map WebHelp Responsive. In that scenario there is a tab called Feedback. In Oxygen v 21 there were 2 webhelp scenarios - one with and one without Feedback. However, the scenario named ... with feedback did not have the tab feedback, while the other scenario had that tab. A confusing bug as it seems. Now it looks like scenario DITA Map Webhelp Responsive with Feedback is gone in v 24.0 and later, only 1 Webhelp scenario remains, but still with the Feedback tab. Our problem is that when we install the webhelp (with feedback function) in our system it doesn't have write permission on the file system, so it doesn't work. Has the feedback version of the webhelp scenario really been removed? Or is it just somehow missing on our system?
thanks, Mikael

Hello,

For the issue you reported initially:

I upgraded to Oxygen v 24.1 and I can see that DITA OT v. 3.7.0 is used, but I still get the same result: transformation fails with error Cannot read field "result" because "fi" is null.. I will try to provide samples for troubleshooting as you instructed.

Indeed, you should send us a sample DITA Map files hierarchy in an as minimal form as possible that we could use to reproduce the issue.
As for what it takes the old DITA Map Webhelp Responsive with Feedback transformation, that was indeed removed, as we now have a dedicated, more advanced platform for comments - Oxygen Feedback - which comes as a separate product and is easy to configure, integrate and use, thanks to its user-friendly UI.
The current Feedback system can be used only if the WebHelp output is hosted on a webserver, it cannot be used with a local WebvHelp output accessed with the file:// protocol .
You could switch to the new Feedback (which is compatible with the old comments database) system without loosing any data, if you choose to go with the Enterprise edition for Feedback (which can be hosted at your side).

Regards,
Costin

Hi Costin,
resuming this case after some time..
We have quite hard restrictions on sending files outside the site here. Is there any way we can troubleshoot this with help of the printouts that Oxygen and DITA-OT give? Or any other suggestion you have that i might try?
thanks,
Mikael

Hi Mikael,

Even if we strive to solve as many issues encountered by our users as possible, I'm afraid that we could not fix a problem without reproducing it first.
You could send us the transformation console log, but it would be best to send us a small sample DITA Map (in an as minimal form as possible) that we could use to reproduce the issue.
One thing that comes to my mind is that you should open the main DITA Map in the DITA Maps Manager view and try running the "Validate and Check and Completeness" action, to identify any possible validation errors, which you should then try to resolve, prior to running the transformation scenario.

Regards,
Costin

Hello again Costin,
I managed now to pinpoint this problem, it happens when a dita file uses content reuse, with Content source = location.
Failure output in the log: We have Oxygen v.24.1, use transformation scenario DITA Map Webhelp Responsive, parameters fix.external.refs.com.oxygenxml=true, generate.copy.outer=3.
I also tried moving the referenced file inside the same folder as the dita map, but got the same result.
Are you able to deduct anything from this?
I tried to attach a log file, but it didn't work. Isn't .txt allowed?
regards, Mikael

Hi Mikael,

We have two issues registered on our issue tracker that describes the error you obtain.
One, which was fixed, happened when transforming topics with apos character in name, and the other, not fixed yet when there are references to an image ending in "/".
Please check if you fall in any of these cases.

Best regards,
Marius

Thanks Marius.
Do you mean the apostrophe character ,

'

? And do you mean in the file name?
About the other case, "references to an image ending in "/"". I don't have any instance of that. But I discovered that an image with the "#" character in the file name gives the same error. When I changed those file names it worked fine.
Do you plan to correct this? Or don't you see it as a fault, more like a rule: Don't use # or / in image file names?
regards, Mikael

Hi Mikael,

Yes, the apostrophe character in file names produced that error.
You are right, I see now that the # character in an image file name also gives that error.
To respond to your questions, I'll also add the case of # character in the opened issue we have logged and we'll update this forum thread once we have a fix.
On the other hand, having the # character in images file names produces validation errors in the topics that contain such characters, so you may want to correct that.

Best regards,
Marius