The error "SEVERE: (EmptyTable)" should clearly state on which adoc file it occurs.

[ge0ffrey]

After converting the Drools 300 pages to asciidoc, we get this error when trying to generate the PDF. I presume we have an empty table somewhere, but as we have 80 tables and none of them look suspicious, it's would help enormously if this error actually reported the adoc file (and if the line number if possible).

Oct 05, 2016 1:55:26 PM org.asciidoctor.internal.JRubyAsciidoctor renderFile
SEVERE: (EmptyTable) data must be a non-empty, non-nil, two dimensional array of cell-convertible objects
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
...
[ERROR] Failed to execute goal org.asciidoctor:asciidoctor-maven-plugin:1.5.3:process-asciidoc (generate-pdf) on project drools-docs: Execution generate-pdf of goal org.asciidoctor:asciidoctor-maven-plugin:1.5.3:process-asciidoc failed: org.jruby.exceptions.RaiseException: (EmptyTable) data must be a non-empty, non-nil, two dimensional array of cell-convertible objects -> [Help 1]

[mojavelinux]

The issue of an empty table was fixed in alpha.13 (see #480). You'll either need to configure your build to use that gem directly (which is possible) or wait for the new release of AsciidoctorJ PDF.

I agree that having line numbers in messages is essential. Unfortunately, there are some areas in the parser where this information is not yet available (due to how it is implemented). The goal is to have every message include the line and file information.

[ge0ffrey]

For reference, this is how our invalid code looked like:

[cols="1a,"]
|===
| Foo
|===

and of course that should be without the ",":

[cols="1a"]
|===
| Foo
|===

So given this info, this might be different from #480 but related.

[ge0ffrey]

I am less worried about the line number than about the filename. I had to do a manual bisect (commenting out half of the adoc files at a time) to figure out the invalid adoc file. Once I found the correct file, finding the correct table (so line number) was much less labor intensive (only 4 tables in that file).

[mojavelinux]

It looks like the example you gave is still a bug. It complains about the width of the table being larger than the width of the page. I'm going to file a separate issue for that since it's more specific than this issue.

I understand having file information (and ideally line information) makes things easier (even possible) to debug. If I had the information, I would put it in the message. But the problem is, core simply doesn't have that information at that point in the parser (regarding tables), so that deficiency needs to be addressed.

[mojavelinux]

I noticed you are using the AsciiDoc table cell. Keep in mind that's not yet supported in Asciidoctor PDF.

[mojavelinux]

I did some further refinements on this. We now have tests for it. Also, a warning will be issued. If you have the sourcemaps option enabled on the document (which you can set via Maven or Gradle), it will include information about where the table is located.