You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When turning on line numbers for code blocks with imported files, the lines are indented in the generated pdf output. The amount of indentation seems to increase with the length of the included code.
I understand that indentation is indeed required for right-alingning the line numbers. However, if the number of lines of code goes into the hundreds or thousands, the calculation for the indentation seems to be buggy, because the level of indentiation is far too big. With 1000 code lines the output has additional blank lines ...
asciidoctor -r asciidoctor-pdf -b pdf line-num-issue.adoc
Note on performance:
Also when you increase the number of nodes even further, say 10000, and include the resulting file with line numbers, you will notice that generation of the pdf takes very long ... and indeed will complete only when increasing the available stack/heap for the jvm.
I used:
alias jruby='jruby -J-Xms2048m -J-Xmx4096m'
for my concrete use case where I included a generated xsd of 16000 lines. That took like 1.5 hrs to generate the pdf and the listing was faily useless due to excessive indentation leading to multiple blank lines ...
The text was updated successfully, but these errors were encountered:
How right you are. I was using the following to determine the number of digits in the largest line number:
linenum_w=(linenum / 10) + 1
Obviously, that's not going to work :/
Here's the Ruby way of doing it:
linenum_w=linenum.to_s.size
(That's effective the same as taking the log base 10, but much faster).
As for the performance, there's not much we can do. Prawn doesn't give us the proper toolset for page overflow, so we have to do a lot of work to layout a source block, including writing to a scratch document. The line numbers add about a 20% overhead, but the bulk of the time is in the handling of the source block itself.
The reason the line numbers add such a big overhead is because we have to go through the code token by token to find all the endlines, then rebuild the fragments to add the line numbers in front. This could be made more efficient if Rouge weaved in the line numbers for us or gave us the tokens organized by line already.
mojavelinux
added a commit
to mojavelinux/asciidoctor-pdf
that referenced
this issue
Aug 8, 2016
When turning on line numbers for code blocks with imported files, the lines are indented in the generated pdf output. The amount of indentation seems to increase with the length of the included code.
I understand that indentation is indeed required for right-alingning the line numbers. However, if the number of lines of code goes into the hundreds or thousands, the calculation for the indentation seems to be buggy, because the level of indentiation is far too big. With 1000 code lines the output has additional blank lines ...
The resulting pdf is attached as
line-num-issue.pdf
You can reproduce it by following the steps outlined below
Here is a sample .adoc that includes xml code files of increasing length w/o and with line numbers:
And here's some code to generate the xml files to include:
Save that to a file and call it with:
ruby <file-name-chosen> 10
to generated a test10.xml containing the following xml code:
You can generate the other two files with
ruby <file-name-chosen> 100
and
ruby <file-name-chosen> 1000
respectively.
Test data needs to be in a ./src folder
Then generate the document as follows:
asciidoctor -r asciidoctor-pdf -b pdf line-num-issue.adoc
Note on performance:
Also when you increase the number of nodes even further, say 10000, and include the resulting file with line numbers, you will notice that generation of the pdf takes very long ... and indeed will complete only when increasing the available stack/heap for the jvm.
I used:
alias jruby='jruby -J-Xms2048m -J-Xmx4096m'
for my concrete use case where I included a generated xsd of 16000 lines. That took like 1.5 hrs to generate the pdf and the listing was faily useless due to excessive indentation leading to multiple blank lines ...
The text was updated successfully, but these errors were encountered: