Closed rillbert closed 3 years ago
mojavelinux
commented
4 years ago will fail with an error message that is quite cryptic and makes it difficult to track what is wrong with the source.
It's doing exactly what it should, which is to provide enough information to the developer to fix the bug. Crashes aren't supposed to be pretty because under normal circumstances, they aren't suppose to happen.
mojavelinux
commented
4 years ago This is a bug in Asciidoctor Mathematical. It is matching normal table cells, but processing them as paragraphs.
mojavelinux
commented
4 years ago @ProgramFan Since version 2.0.0, Asciidoctor matches normal table cells when you use find_by. A quick fix for this is to exclude the :table_cell context from the initial call to find_by to retrieve prose blocks:
unless (prose_blocks = document.find_by {|b|
((b.content_model == :simple && (b.subs.include? :macros)) || b.context == :list_item) && b.context != :table_cell
}).nil_or_empty?
prose_blocks.each do |prose|
handle_prose_block prose, mathematical, image_output_dir, image_target_dir, format, inline
end
end
Alternately, you could add the condition inside the each loop, and call the appropriate method.
mojavelinux
commented
3 years ago This is a duplicate of #61. At the time of writing, a fix is pending.
Hello there,
I discovered that if I use inline stem blocks in table cells without specifying the 'a' attribute at the beginning of the cell, asciidoctor-pdf will fail with an error message that is quite cryptic and makes it difficult to track what is wrong with the source.
This can be reproduced by eg removing the leading 'a' character in line 82 in the attached source file. pdf_stem_bug.txt
(this was discovered at the same time as asciidoctor/asciidoctor-pdf#1516 but I thought it best to separate these two issues).
Running with the --trace option, the following stack trace is generated: