Can I do Better at Loggin things ?

[desaisam]

Team,

I am using DITAOT 3.3.4 and everything works fine. However, in a collaborative environment when someone makes a mistake the ANT crashes and PDFs do not get generated.

For example the error below :

This log message is impossible to comprehend by a non technical person. and usually spend hours in debugging this.

I want to produce logs which are to be consumed by non Technical people ( like Tech Writers) . Any approaches or suggestions on how can I achieve this. This will be really helpful as we spend lot of time usually to find the root cause of the error.

Thanks in advance,
Sam

[raducoravu]

When the XSL-FO output is compiled to PDF it is usually too late to give meaningful error messages as the XSL-FO content does not retain information about the original DITA content which generated it.
In the case of the particular error message you posted probably the initial DITA table was somehow broken or profiling filters were used which removed all rows from it. But it could be something else, maybe an XSL-FO table is created from another DITA element, maybe it's created from a DITA <dl> element. In such cases I would open the XSL-FO file at the specified line (1930) and try to determine what text content appears there and where that text content was placed in the original DITA content. But this is not something a technical writer would do. Also ideally the technical writers would not be the ones in charge of checking if the PDF is properly generated, there would be someone in the team in charge of debugging and customizing the output formats.

In such cases it would be best to add more validation to the DITA content to take care of such situations which may arise in the PDF generation part.

So maybe you can impose more validation checks on the editing side.
For example I work for Oxygen XML Editor and as a commercial application it has a "Validate and check for completeness" action which performs lots of validation checks on the edited DITA content:

https://www.oxygenxml.com/doc/versions/24.1/ug-editor/topics/dita-map-validate.html

[chrispy-snps]

@desaisam - another technique I use is to successively keep deleting content that is not related to the problem:

• Keep deleting topic references from your map until you narrow down to the topic that causes the crash.
• Keep deleting content from your topic until you narrow down to the content that causes the crash.

A "binary search" approach can help. Delete (or comment out!) half of what you are looking to test. If the problem is resolved, then restore that content and delete the other half. This can help you quickly narrow down the problematic content.